Re: NFS mountd version 3 over TCP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/27/11 21:23, Steve Wills wrote: On 08/27/11 20:55, Rick Macklem wrote: I don't know why the nfsd wouldn't be able to bind(2) to port #2049 a second time for UDP, but someone on the net side might know? (Just in case it is a problem that has already been fixed, I'd try a newer kernel.) Will do, see below. The new server was broken by r224778 on Aug. 11 and fixed by r224911 on Aug. 16. (I recall you mentioning Aug. 11?) My kernel is from Aug 13, so definitely would fall into that range. I'll update and rebuild and see how it goes. After working around the /dev/stdout issue by booting an old kernel and doing a buildworld from there, I was able to update my kernel to todays sources. ESXi is now able to mount the nfs share. However, when I attempt to start a VM, it reports: Failed to power on VM. Unable to retrieve the current working directory: 0 (Input/output error). Check if the directory has been deleted or unmounted. and FILE: File_Cwd: getcwd() failed: Input/output error I have tcpdump output available here: http://people.freebsd.org/~swills/nfs2.pcap if that helps. Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWzShAAoJEPXPYrMgexuhxo0H/0ALErvMrpcxtkuUv07ipj0O Z8p3YkMFkckSy6s0QCAOCVgjbqZptCkKg96vMehG3nI5o2HtA43h5y6UNvMi1FWE WOiIFbzXkgfn1pubv2YyFwaDK1aFXMswwYaCHSP7a+K8fpjDOiR5ZnhhyXcb7k1X YmURkSEbLbngLdIfywPATSiby9PyFVqyMjhU3yW/Y8QLueEjK4xq5RsbmU1Qmv2B bjA11x9birNvc//iBp6zTqBP752soqK+M9aXrjjm9GzhN0UeKdXseWt9zd3mu2qs cfPUqz7DSATQNxwfpqIGnE4naYzPyKPbDbv6k5lKDjmmHn2O7VzXQXimjE6sT3o= =Dpjc -END PGP SIGNATURE- ___ 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
hd numbering in 9.0beta1
Hi everybody, I would point out a problem related with the new way, coming in 9.0, to hard disks numbering. As far I remember (5.0 ?), hardware detection of H.D.'s at O.S. boot-up numbered every channel potentially able to attach a disk to, and tagged the disks really attached with the number of his control channel; the sequence (from lowers to highers numbers) begins with scsi or scsi-like (e-sata, usb, fire-wire,...) controllers and ends with the controllers directly depending from the chipset (sata at this time). Such strategy allows to attach easily a new mass-storage device without modifying the disks numbering and thus the relevant fstab files. 9.0beta1 use a different numbering strategy,(with a similar sequence in harware detection) tagging succesively detected disks with adjacent numbers. Please, let me show an example from my computer: lines relevant to hard disks from /var/log/messages (recently installed FreeBSD-9.0beta1): --- Aug 26 09:21:30 P5E-WS kernel: pci2: ACPI PCI bus on pcib8 Aug 26 09:21:30 P5E-WS kernel: siis0: SiI3132 SATA controller port 0xac00-0xac7f mem 0xfe6ffc00-0xfe6ffc7f,0xfe6f8000-0xfe6fbfff irq 17 at device 0.0 on pci2 Aug 26 09:21:30 P5E-WS kernel: siisch0: SIIS channel at channel 0 on siis0 Aug 26 09:21:30 P5E-WS kernel: siisch1: SIIS channel at channel 1 on siis0 Aug 26 09:21:30 P5E-WS kernel: ada0 at siisch1 bus 0 scbus6 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada0: WDC WD20EARS-00MVWB0 51.0AB51 ATA-8 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada0: Command Queueing enabled Aug 26 09:21:30 P5E-WS kernel: ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada0: Previously was known as ad16 Aug 26 09:21:30 P5E-WS kernel: ada1 at ata3 bus 0 scbus9 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada1: WDC WD3200AAKS-00B3A0 01.03A01 ATA-8 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada1: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada1: Previously was known as ad18 Aug 26 09:21:30 P5E-WS kernel: ada2 at ata4 bus 0 scbus10 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada2: Maxtor 6V160E0 VA111630 ATA-7 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada2: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada2: Previously was known as ad20 Aug 26 09:21:30 P5E-WS kernel: ada3 at ata5 bus 0 scbus11 target 0 lun 0 Aug 26 09:21:30 P5E-WS kernel: ada3: SAMSUNG HD502IJ 1AA01110 ATA-7 SATA 2.x device Aug 26 09:21:30 P5E-WS kernel: ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) Aug 26 09:21:30 P5E-WS kernel: ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) Aug 26 09:21:30 P5E-WS kernel: ada3: Previously was known as ad22 - Well, the system remembers the previous numbering (in my example, numbering from 8.2 release, as production release installed on a different slice), avoiding confusion. But the funny things are that : 1- AMI Bios (MBR style) in my Asus M.B.(3 years old) shows, in the POST table relevant to disks, only the 3 first ones, i.e does not show the disk controlled by the SiI3132 pci-card; ami-bios don't list this disk as bootable in the disk-boot-order selection menu, and it's impossible to select it as a bootable disks. (but this disk appears correctly detected by the pci-card internal bios.); and I suppose the ami-bios detects and records the scsi-like disk, but hide it to the user. 2- Grub detects as hd0,hd1,hd2,hd3 the disks appearing in 9.0 as ada1, ada2, ada3, ada0 (i.e. Grub numbers with the scsi-like ones at the end and the chipset-controlled ones at the beginning).(Grub is said to extract the info from bios). At this point, no real problem, as Bsd users warn carefully in the management of their disks between different releases of the O.S. But adding a new hard disk will shift one, more, or all the previous numbers, (depênding from the channel the new disk is attached to), making the /etc/fstab files irrelevant, and leading kernel in panic at boot-up. Well, I could, after adding a new disk, boot-up from a rescue disk to update files, (or rootmount manually, log as single, edit the proper config files, ...) but really the old numbering strategy was less painfull ! And I would panic if I have to explain that process to a newbee. Perhaps I miss some important new feature introduced in 9.0 to work around that problem ? Moreover, 9.0beta1 installs very easily and works fine; I am near to agree with the recently stated opinion that 9.1 release will never be necessary !! Congratulations to the team Roger As frenchie, I apologize for
Re: hd numbering in 9.0beta1
on 29/08/2011 10:10 Roger Genre said the following: Perhaps I miss some important new feature introduced in 9.0 to work around that problem ? Most likely you just overlook a CAM feature that you have not needed before. Please see cam(4), search for 'wired'. -- Andriy Gapon ___ 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: hd numbering in 9.0beta1
On Mon, 29 Aug 2011, Roger Genre wrote: Hi everybody, I would point out a problem related with the new way, coming in 9.0, to hard disks numbering. As far I remember (5.0 ?), hardware detection of H.D.'s at O.S. boot-up numbered every channel potentially able to attach a disk to, and tagged the disks really attached with the number of his control channel; the sequence (from lowers to highers numbers) begins with scsi or scsi-like (e-sata, usb, fire-wire,...) controllers and ends with the controllers directly depending from the chipset (sata at this time). Such strategy allows to attach easily a new mass-storage device without modifying the disks numbering and thus the relevant fstab files. 9.0beta1 use a different numbering strategy,(with a similar sequence in harware detection) tagging succesively detected disks with adjacent numbers. The best way I can put it has already been noted in the archives several months back: - http://lists.freebsd.org/pipermail/freebsd-current/2011-April/024110.html - http://lists.freebsd.org/pipermail/freebsd-current/2011-May/024495.html - http://lists.freebsd.org/pipermail/freebsd-current/2011-April/024233.html I don't have the corresponding commits right now, but I could dig them up as they spawned a large discussion thread as well. The basic gist is that several folks agreed that: 1. GEOM/UFS labels were the only way to go. 2. There are some caveats to using GEOM labels that discourages use as a means of deterministically determining mountpoints. 3. A compatibility shim was added for ata - atacam transitioning; see kern.cam.ada.legacy_aliases in /sys/cam/ata/ata_da.c Cheers, -Garrett ___ 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: hd numbering in 9.0beta1
On Mon, Aug 29, 2011 at 2:10 PM, Roger Genre genre.ro...@orange.fr wrote: But adding a new hard disk will shift one, more, or all the previous numbers, (depênding from the channel the new disk is attached to), making the /etc/fstab files irrelevant, and leading kernel in panic at boot-up. there's a good reason we have geom_label now. My fstab now looks like this: /dev/ufs/root3 / ufs rw,noatime 1 1 /dev/label/swap3 none swap sw 0 0 proc /proc procfs rw 0 0 -- O ascii ribbon campaign - stop html mail - www.asciiribbon.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: possible mountroot regression
on 27/08/2011 18:16 Marcel Moolenaar said the following: On Aug 26, 2011, at 2:07 PM, Andriy Gapon wrote: It seems that after the introduction of the mountroot scripting language a user now has exactly one chance to try to specify a correct root device at the mountroot prompt. I am not sure that that is convenient/enough. This is no different from before. Are you sure? I remember trying multiple (incorrect) possibilities at the prompt and not getting the panic. But I know that sometimes I have cases of false memories, so _I_ am not sure. -- Andriy Gapon ___ 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: mutex pf task mtx owned at /usr/src/sys/contrib/pf/net/if_pfsync.c:3163
Hi Matthew, On Fri, Aug 26, 2011 at 11:51 PM, Matthew Economou mxecono...@gmail.comwrote: I recently upgraded a firewall I'm using for performance testing from a March-ish 9-CURRENT to 9.0-BETA1 (csup run August 21 around 12:00 AM EDT). It's basically a GENERIC kernel with debugging disabled and things like IPsec and ALTQ enabled. Since the upgrade, after approximately an hour after it boots, the firewall stops passing any traffic (IPv4 and IPv6). OpenVPN, for example, logs the following errors: write UDPv4: Operation not permitted (code=1) Quagga, for another example, logs something similar: ripd[1696]: can't send packet : Operation not permitted0 ospfd[1702]: *** sendmsg in ospf_write failed to 172.30.0.3, id 0, off 0, len 76, interface tap0 mtu 1500: Operation not permitted If I try to ping something from the console, I get the same error message: # ping 4.2.2.2 ping: sendto: Operation not permitted It appears that PF isn't removing any entries from the state table. Note that the state table size is at its default of 1 (which correlates to the amount of memory installed on the firewall - 256 MB). State Table Total Rate current entries10013 searches 554801 13.4/s inserts100130.2/s removals 00.0/s I've tried both my current (unmodified and working prior to the upgrade) and experimental PF configurations, neither of which have any effect on the problem. Reloading the PF configuration (/etc/rc.d/pf reload) or restarting PF altogether (/etc/rc.d/pf restart) also have no effect. Only if I shut down PF completely (/etc/rc.d/pf stop) do I regain network connectivity - I can do things like ping hosts (IPv4 and IPv6), browse the web, and pass traffic that's just routed through the firewall (i.e., not requiring NAT). Clearing the state table (pfsync -F state) has no effect. The kernel I'm was running had debugging disabled for performance testing purposes, so I booted a proper debug kernel. It panicked in pfsync_send_plus as soon as init enabled PF (backtrace included below). Starting pflog. pflog0: promiscuous mode enabled Aug 25 20:54:21 pflogd[1611]: [priv]: msg PRIV_OPEN_LOG received Enabling pfpanic: mutex pf task mtx owned at /usr/src/sys/contrib/pf/net/if_pfsync.c:3163 cpuid = 0 KDB: enter: panic [ thread pid 1619 tid 100053 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db bt Tracing pid 1619 tid 100053 td 0xc23da2e0 kdb_enter(c09777c9,c09777c9,c0975d7b,c6fd79e0,0,...) at kdb_enter+0x3a panic(c0975d7b,c0946080,c0944e87,c5b,c6fd7a0c,...) at panic+0x134 _mtx_assert(c0a1b388,0,c0944e87,c5b,c6fd7a24,...) at _mtx_assert+0x127 pfsync_send_plus(c6fd7a24,18,10,ad6,100,...) at pfsync_send_plus+0xf2 pfsync_clear_states(a218d664,c236fb78,c0945f1c,635,c09ae167,...) at pfsync_clear_states+0x8d pfioctl(c22a0800,c0cc4412,c236fb00,3,c23da2e0,...) at pfioctl+0x1b90 devfs_ioctl_f(c23ce578,c0cc4412,c236fb00,c216ce80,c23da2e0,...) at devfs_ioctl_f+0x10b kern_ioctl(c23da2e0,3,c0cc4412,c236fb00,1fd7cec,...) at kern_ioctl+0x21d ioctl(c23da2e0,c6fd7cec,c6fd7d28,c097d93a,0,...) at ioctl+0x134 syscallenter(c23da2e0,c6fd7ce4,c6fd7ce4,0,0,...) at syscallenter+0x263 syscall(c6fd7d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281e6263, esp = 0xbfbfe8ac, ebp = 0xbfbfe998 --- db I'm at a loss as to how to proceed. Is this a known problem with PF? Can anyone suggest a work-around? I ran into the same problem on my NAT-box. According to ome other PRs (kern/159390 and kern/158873) the problem lies in pfsync. The (still open) PRs contain both a patch (didn't test that) and the assumption that pulling a newer version to FreeBSD might help. Also, they suggest as a workaround to not compile device pfsync into the kernel. Seems to work for me (not yet tested in detail though), don't know if this is a feasable solution for you. Hope this helps Johannes ___ 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
PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
Hello out there. Just read this a day ago at Phoronix: http://www.phoronix.com/scan.php?page=news_itempx=OTg0MQ I've also read that there is work done on the PTX assembly backend in LLVM for generation code for nVidia GPUs. I'm still grasping for the silky fathem having GPGPU on FreeBSD anyway like CUDA or OpenCL as the Linux and Windows fellows already have as well as the guys from OS X. Since nVidia offers 64bit ready BLOBs for their nice GPUs, I still hope that with LLVM, and maybe a proper OpenCL frontend like CLANG, FreeBSD users will have the chance to execute OpenCL code on a GPU. We use this stuff in science for now (and its done exclusiveley on Linux so far, since we use the CUDA SDK to generate OpenCL 1.1 code executed on TESLA and GTX570 graphics boards which give us impressive performance for our astrodynamical modelling ...). Sorry, if someone feels bothered by my repetitive bringing up this subject ... I still does not have lost all hope for FreeBSD. oh ___ 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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
Hi, http://forums.nvidia.com/index.php?showtopic=38242 Post 18 This indicates the driver supports CUDA somehow. What's missing is a FreeBSD runtime. Can someone please do some legwork with this and see if it's possible to bring the Linux CUDA SDK up in the linuxulator? Adrian On 29 August 2011 18:13, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: Hello out there. Just read this a day ago at Phoronix: http://www.phoronix.com/scan.php?page=news_itempx=OTg0MQ I've also read that there is work done on the PTX assembly backend in LLVM for generation code for nVidia GPUs. I'm still grasping for the silky fathem having GPGPU on FreeBSD anyway like CUDA or OpenCL as the Linux and Windows fellows already have as well as the guys from OS X. Since nVidia offers 64bit ready BLOBs for their nice GPUs, I still hope that with LLVM, and maybe a proper OpenCL frontend like CLANG, FreeBSD users will have the chance to execute OpenCL code on a GPU. We use this stuff in science for now (and its done exclusiveley on Linux so far, since we use the CUDA SDK to generate OpenCL 1.1 code executed on TESLA and GTX570 graphics boards which give us impressive performance for our astrodynamical modelling ...). Sorry, if someone feels bothered by my repetitive bringing up this subject ... I still does not have lost all hope for FreeBSD. oh ___ freebsd-performa...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to freebsd-performance-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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
On Mon, 29 Aug 2011 20:12:54 +0800 Adrian Chadd adr...@freebsd.org wrote: Hi, http://forums.nvidia.com/index.php?showtopic=38242 Post 18 This indicates the driver supports CUDA somehow. What's missing is a FreeBSD runtime. Can someone please do some legwork with this and see if it's possible to bring the Linux CUDA SDK up in the linuxulator? Yes that's possible. jhb@ wrote a little tutorial some time ago: http://blogs.freebsdish.org/jhb/2010/07/20/using-cuda-with-the-native-freebsdamd64-nvidia-driver/ -- Homepage: www.yamagi.org Jabber: yam...@yamagi.org GnuPG/GPG:0xEFBCCBCB pgpznO5jlYlxw.pgp Description: PGP signature
Re: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
On Mon, Aug 29, 2011 at 2:12 PM, Adrian Chadd adr...@freebsd.org wrote: Hi, http://forums.nvidia.com/index.php?showtopic=38242 Post 18 This indicates the driver supports CUDA somehow. What's missing is a FreeBSD runtime. Can someone please do some legwork with this and see if it's possible to bring the Linux CUDA SDK up in the linuxulator? Just to underscore this. There are a number of us that can contribute to making this happen. However, it is not clear what the missing pieces are. Cheers Adrian On 29 August 2011 18:13, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: Hello out there. Just read this a day ago at Phoronix: http://www.phoronix.com/scan.php?page=news_itempx=OTg0MQ I've also read that there is work done on the PTX assembly backend in LLVM for generation code for nVidia GPUs. I'm still grasping for the silky fathem having GPGPU on FreeBSD anyway like CUDA or OpenCL as the Linux and Windows fellows already have as well as the guys from OS X. Since nVidia offers 64bit ready BLOBs for their nice GPUs, I still hope that with LLVM, and maybe a proper OpenCL frontend like CLANG, FreeBSD users will have the chance to execute OpenCL code on a GPU. We use this stuff in science for now (and its done exclusiveley on Linux so far, since we use the CUDA SDK to generate OpenCL 1.1 code executed on TESLA and GTX570 graphics boards which give us impressive performance for our astrodynamical modelling ...). Sorry, if someone feels bothered by my repetitive bringing up this subject ... I still does not have lost all hope for FreeBSD. oh ___ freebsd-performa...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to freebsd-performance-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 ___ 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: x11/nvidia-driver / Compilation has failed
Could I test your patch for nvidia-driver, too? I cannot find your patch in this mail. ___ 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: x11/nvidia-driver / Compilation has failed
2011/8/29 ken k...@tydfam.jp: Could I test your patch for nvidia-driver, too? I cannot find your patch in this mail. I took the patch in : http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026515.html And it worked for me. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
On 08/29/11 14:31, Yamagi Burmeister wrote: On Mon, 29 Aug 2011 20:12:54 +0800 Adrian Chaddadr...@freebsd.org wrote: Hi, http://forums.nvidia.com/index.php?showtopic=38242 Post 18 This indicates the driver supports CUDA somehow. What's missing is a FreeBSD runtime. Can someone please do some legwork with this and see if it's possible to bring the Linux CUDA SDK up in the linuxulator? Yes that's possible. jhb@ wrote a little tutorial some time ago: http://blogs.freebsdish.org/jhb/2010/07/20/using-cuda-with-the-native-freebsdamd64-nvidia-driver/ With beginnig of 2011 I tried everything possible to make CUDA SDK running on FreeBSD 9-CUR/amd64. For those interested in this subject, the mentioned forae entries and that mentioned tutorial are a bit outdated. I tried the tutorial mentioned by Yamagi, but I had never real success installing SDK 3.2/32bit. For serious scientific usage 32bit isn't a great deal, my model code highly depends on 64 bit in the portions were the model is calculated on the cpu, not the GPU. Anyway, having CUDA working in the Linuxulator would be great. But having something OpenCL-ish natively would be a real quantum leap ... And 64bit. My lectures in building compilers I liestend to is quite a time ago, so as far as I know, nVidias driver BLOB is executing some binary code that is only applicable for the GPU. Further, the OpenCL code or even CUDA code of a C/C++ software is runtime compiled when accessed and transfered to the GPU/driver, so the nvcc compiler is a sine conditio qua non in this game, so far. My thinking: eliminating the need of the nvcc producing PTX code/binary code via LLVM could be a solution. But at this point I do not know whether PTX has to translated again in binary code via nvcc to make the GPU understand what I want. By the beginning of this year Pathscale introduced a kind of compiler capable of HMPP, a very smart model like OpenMP. This compiler seems not to be ready by now and I never got access to a beta version to test whether it was capable of compiling CUDA ready code. As far as I know, HMPP is also an open standard. Well, conclusively, there seems no real solution to be present for FreeBSD by now (as I mentioned, the Linuxulator is no real alternative due to its 32bit limitations). oh ___ 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: NFS mountd version 3 over TCP
Steve Wills wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/27/11 21:23, Steve Wills wrote: On 08/27/11 20:55, Rick Macklem wrote: I don't know why the nfsd wouldn't be able to bind(2) to port #2049 a second time for UDP, but someone on the net side might know? (Just in case it is a problem that has already been fixed, I'd try a newer kernel.) Will do, see below. The new server was broken by r224778 on Aug. 11 and fixed by r224911 on Aug. 16. (I recall you mentioning Aug. 11?) My kernel is from Aug 13, so definitely would fall into that range. I'll update and rebuild and see how it goes. After working around the /dev/stdout issue by booting an old kernel and doing a buildworld from there, I was able to update my kernel to todays sources. ESXi is now able to mount the nfs share. However, when I attempt to start a VM, it reports: Failed to power on VM. Unable to retrieve the current working directory: 0 (Input/output error). Check if the directory has been deleted or unmounted. and FILE: File_Cwd: getcwd() failed: Input/output error I have tcpdump output available here: http://people.freebsd.org/~swills/nfs2.pcap if that helps. I think it did. Lookup of .. was failing. I think that was because ni_strictrelative (added for capabilities) wasn't initialized and happened to be non-zero. Please try this patch and let us know if it helps: --- fs/nfsserver/nfs_nfsdport.c.sav 2011-08-29 11:05:00.0 -0400 +++ fs/nfsserver/nfs_nfsdport.c 2011-08-29 11:29:43.0 -0400 @@ -282,6 +282,10 @@ nfsvno_namei(struct nfsrv_descript *nd, *retdirp = NULL; cnp-cn_nameptr = cnp-cn_pnbuf; + /* Initialize new fields for capabilities. */ + ndp-ni_strictrelative = 0; + ndp-ni_rightsneeded = 0; + ndp-ni_baserights = 0; /* * Extract and set starting directory. */ It's also at (in case white space gets munged) http://people.freebsd.org/~rmacklem/dotdot.patch Thanks for reporting this, I'm not sure when these fields not being initialized would have been noticed otherwise, rick Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOWzShAAoJEPXPYrMgexuhxo0H/0ALErvMrpcxtkuUv07ipj0O Z8p3YkMFkckSy6s0QCAOCVgjbqZptCkKg96vMehG3nI5o2HtA43h5y6UNvMi1FWE WOiIFbzXkgfn1pubv2YyFwaDK1aFXMswwYaCHSP7a+K8fpjDOiR5ZnhhyXcb7k1X YmURkSEbLbngLdIfywPATSiby9PyFVqyMjhU3yW/Y8QLueEjK4xq5RsbmU1Qmv2B bjA11x9birNvc//iBp6zTqBP752soqK+M9aXrjjm9GzhN0UeKdXseWt9zd3mu2qs cfPUqz7DSATQNxwfpqIGnE4naYzPyKPbDbv6k5lKDjmmHn2O7VzXQXimjE6sT3o= =Dpjc -END PGP SIGNATURE- ___ 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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
Hi all, I'm involved in the Phoronix test suite. I'm on freebs d-performance, so if you have any questions - CC me or freebsd-performance. Regards, Matthee _ On Aug= 29, 2011 5:38 AM, Yamagi Burmeister li...@yamagi.org wrote: On Mon, 29 Aug 2011 20:12:54 +0800 Adrian Chadd adrian@freeb= sd.org wrote: Hi, http://forum= s.nvidia.com/index.php?showtopic=38242 Post 18 Thi= s indicates the driver supports CUDA somehow. What's missing is a = ; FreeBSD runtime. Can someone please do some legwor= k with this and see if it's possible to bring the Linux CUDA SDK= up in the linuxulator? Yes that's possible. jhb@ wrote a litt= le tutorial some time ago: http://blogs.freebsdish.org/jhb/2010/07/2 0/using-cuda-with-the-native-freebsdamd64-nvidia-driver/ -- = Homepage: www.yamagi.org Jabber: yam...@yamagi.or= g GnuPG/GPG: 0xEFBCCBCB ___ 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: possible mountroot regression
On Aug 29, 2011, at 1:21 AM, Andriy Gapon wrote: on 27/08/2011 18:16 Marcel Moolenaar said the following: On Aug 26, 2011, at 2:07 PM, Andriy Gapon wrote: It seems that after the introduction of the mountroot scripting language a user now has exactly one chance to try to specify a correct root device at the mountroot prompt. I am not sure that that is convenient/enough. This is no different from before. Are you sure? I remember trying multiple (incorrect) possibilities at the prompt and not getting the panic. But I know that sometimes I have cases of false memories, so _I_ am not sure. I'm sure now that we're both not sure :-) It's possible the failure mode varied by how the root mount failed... -- Marcel Moolenaar mar...@xcllnt.net ___ 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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
[snip] 32 bit CUDA support may be limiting to you, but it's: * not necessarily limiting to others; * a good starting point to demonstrate it's actually feasible; * a potential stepping stone to getting 64 bit support of some sort in place (whether it's the push for 64 bit linux support; or to get NVIDIA to notice FreeBSD some more, etc.) So if you want to see 64 bit FreeBSD CRDA support; please start by getting 32 bit support as working as possible, documented, and then as easy to install as you can get it. 2c, 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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
On 08/29/11 08:12, Adrian Chadd wrote: Hi, http://forums.nvidia.com/index.php?showtopic=38242 Post 18 This indicates the driver supports CUDA somehow. What's missing is a FreeBSD runtime. Can someone please do some legwork with this and see if it's possible to bring the Linux CUDA SDK up in the linuxulator? cuda device support is there, what I believe is missing is the compiler, libraries and assorted tools. I currently use cuda on my FreeBSD laptop via the linuxlator (using the gentoo_stage_3 port and chrooting into it). The cuda run time works almost out of the box (if I recall correctly all you need to do is change modprobe since the run time tries to auto load the Linux kernel binary), and from there you can build and run cuda based apps. -- Jacob Frelinger jo...@thecoffinclub.com ___ 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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
On 30 August 2011 01:52, Jacob Frelinger jo...@thecoffinclub.com wrote: cuda device support is there, what I believe is missing is the compiler, libraries and assorted tools. I currently use cuda on my FreeBSD laptop via the linuxlator (using the gentoo_stage_3 port and chrooting into it). The cuda run time works almost out of the box (if I recall correctly all you need to do is change modprobe since the run time tries to auto load the Linux kernel binary), and from there you can build and run cuda based apps. Would you mind writing up a tutorial on how to bootstrap a 32 bit CUDA environment for FreeBSD, using the Linux tools? (I'd love to give this a shot, personally.) 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: ichwd attach failure
On Friday, August 26, 2011 8:48:17 pm Doug Barton wrote: John was working on this, haven't seen an update recently though. I don't currently have a solution, no. It seems that the BIOS just outright lies in this case. ichwd is already engaged in some odd behavior to allocate its resource from isab0 instead of ichwd0. I need to find out what I asked DES to do that but haven't had time to go digging in my mail archive to figure it out. Doug On 08/26/2011 14:24, Mike Tancsa wrote: Got a newish Intel board in and decided to give it a spin. Trying to load the watchdog, I get this error below on CURRENT. Anyone able to get ichwd working on such a motherboard ? full dmesg and devinfo at http://www.tancsa.com/intel.txt and http://www.tancsa.com/intel-asl.txt isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer ichwd0: Intel Cougar Point watchdog timer on isa0 isab0: found ICH10 or equivalent chipset: Intel Cougar Point watchdog timer pcib0: allocated type 4 (0x430-0x437) for rid 0 of ichwd0 pcib0: allocated type 4 (0x460-0x47f) for rid 1 of ichwd0 ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 ppc0: cannot reserve I/O port range pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -- John Baldwin ___ 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
Snapshots fail with UFS+J (was: Re: Fwd: Re: Can *you* UFS snapshot a filesystem with 9.0-BETA1?)
On Sun, Aug 21, 2011 at 12:04:26PM +0200, Hans Ottevanger wrote: On Sat, Aug 20, 2011 at 09:35:01AM +0100, Hugo Silva wrote: Le Thu, 18 Aug 2011 10:22:31 +0100, Hugo Silva h...@barafranca.com a ?crit : Hello, I'm wondering. On a virtual machine (amd64 HVM+PV), it's crashing every time. Not sure if this is SNAFU, as I had never used ufs snapshots on freebsd before. After running mksnap_ffs, ssh stops working (a telnet session doesn't show the sshd banner). The ssh session where the command was run from stops responding, the webserver dies and xm console'ing from the dom0 works, but the VM is unresponsive (ie no login prompt on ENTER). Anyone else seeing the same? I've tried in a FreeBSD guest (9.0-beta1/i386) into VirtualBox and I see a LOR (or looks like a LOR), then the system is freezed. This is 100% reproductible. Unfortunatly, I'm not able to dump a panic or to break into the debugger, so a screenshot : http://user.lamaiziere.net/patrick/public/lormksnap.png You should ask on freebsd-current@ Hi, I can confirm that this happens on real iron too. I use an i386 test installation (P4 2.4 GHz, 2GB RAM, 500GB PATA disk), running 9.0-BETA1 as distributed (with a kernel effectively being GENERIC with devices removed that I don't have). When I try to make a snapshot using cd /usr; mksnap_ffs /usr/.snap/testsnap the system is still responsive for a few seconds, with lots of disk activity, but then it prints the following output on the console (using firewire and dcons to ease capturing): lock order reversal: 1st 0xc5a289e8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:425 2nd 0xdeb3c078 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 3rd 0xc5663af8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:546 KDB: stack backtrace: db_trace_self_wrapper(c09ec6ba,616e735f,6f687370,3a632e74,a363435,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07099eb,c09efe14,c5035308,c5039408,c4fda440,...) at kdb_backtrace+0x2a _witness_debugger(c09efe14,c5663af8,c09df984,c5039408,c0a10ba2,...) at _witness_debugger+0x25 witness_checkorder(c5663af8,9,c0a10ba2,222,0,...) at witness_checkorder+0x839 __lockmgr_args(c5663af8,80100,c5663b18,0,0,...) at __lockmgr_args+0x804 ffs_lock(c4fda568,c0bf1250,c59b9c30,80100,c5663aa0,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0a7fb80,c4fda568,c4fda588,c0a8df20,c5663aa0,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c5663aa0,80100,c0a10ba2,222,c5011e80,...) at _vn_lock+0x5e ffs_snapshot(c54f9798,c52dda60,c0a13fb0,1a2,0,...) at ffs_snapshot+0x14cb ffs_mount(c54f9798,c59b0300,ff,394,3,...) at ffs_mount+0x1c13 vfs_donmount(c59b9b80,11100,c50c7c80,c50c7c80,c59ae580,...) at vfs_donmount+0x11e7 nmount(c59b9b80,c4fdacec,c4fdad28,c09ee6dd,0,...) at nmount+0x84 syscallenter(c59b9b80,c4fdace4,c4fdace4,0,c0ab5690,...) at syscallenter+0x263 syscall(c4fdad28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280db52b, esp = 0xbfbfe59c, ebp = 0xbfbfed18 --- lock order reversal: 1st 0xdeb3c078 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658 2nd 0xc51a72dc snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:818 KDB: stack backtrace: db_trace_self_wrapper(c09ec6ba,662f7366,735f7366,7370616e,2e746f68,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c07099eb,c09efdfb,c5035308,c5039b58,c4fda440,...) at kdb_backtrace+0x2a _witness_debugger(c09efdfb,c51a72dc,c0a10c04,c5039b58,c0a10ba2,...) at _witness_debugger+0x25 witness_checkorder(c51a72dc,9,c0a10ba2,332,c5a28a08,...) at witness_checkorder+0x839 __lockmgr_args(c51a72dc,80400,c5a28a08,0,0,...) at __lockmgr_args+0x804 ffs_lock(c4fda568,deb2434c,10,80400,c5a28990,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0a7fb80,c4fda568,deb243a8,c0a8df20,c5a28990,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c5a28990,80400,c0a10ba2,332,0,...) at _vn_lock+0x5e ffs_snapshot(c54f9798,c52dda60,c0a13fb0,1a2,0,...) at ffs_snapshot+0x295e ffs_mount(c54f9798,c59b0300,ff,394,3,...) at ffs_mount+0x1c13 vfs_donmount(c59b9b80,11100,c50c7c80,c50c7c80,c59ae580,...) at vfs_donmount+0x11e7 nmount(c59b9b80,c4fdacec,c4fdad28,c09ee6dd,0,...) at nmount+0x84 syscallenter(c59b9b80,c4fdace4,c4fdace4,0,c0ab5690,...) at syscallenter+0x263 syscall(c4fdad28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280db52b, esp = 0xbfbfe59c, ebp = 0xbfbfed18 --- After this the system is fully unresponsive and requires a hard reset. Once rebooted, the snapshot file appears to exist, but is unusable. When reverting to just softupdates, i.e. disabling journaling on /usr, everything goes well, except that the same LOR's still do occur, though the addresses differ. My amd64 9.0-CURRENT system, just updated to r225055, has the same issue, but since I do not have WITNESS in the kernel config there, the console output is missing. BTW, this
Re: possible mountroot regression
on 29/08/2011 19:45 Marcel Moolenaar said the following:
On Aug 29, 2011, at 1:21 AM, Andriy Gapon wrote:
on 27/08/2011 18:16 Marcel Moolenaar said the following:
On Aug 26, 2011, at 2:07 PM, Andriy Gapon wrote:
It seems that after the introduction of the mountroot scripting language a
user
now has exactly one chance to try to specify a correct root device at the
mountroot prompt. I am not sure that that is convenient/enough.
This is no different from before.
Are you sure?
I remember trying multiple (incorrect) possibilities at the prompt and not
getting the panic. But I know that sometimes I have cases of false
memories,
so _I_ am not sure.
I'm sure now that we're both not sure :-)
It's possible the failure mode varied by how the root mount
failed...
Judging from the code before r214006 it shouldn't have panic-ed upon such a
failure:
static int
vfs_mountroot_ask(void)
{
char name[128];
char *mountfrom;
char *options;
for(;;) {
...
gets(name, sizeof(name), 1);
if (name[0] == '\0')
return (1);
if (name[0] == '?') {
printf(\nList of GEOM managed disk devices:\n );
g_dev_print();
continue;
}
if (!vfs_mountroot_try(name, NULL))
return (0);
}
}
So this endless loop was exited only if vfs_mountroot_try() returned success
(error == 0) or if a user entered an empty string.
--
Andriy Gapon
___
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: http://www.freebsd.org/marketing/os-comparison.html
27.08.2011 22:13, Hartmann, O. wrote: This website should be brushed up or taken offline! It seems full of vintage stuff from glory days. http://www.freebsd.org/marketing/os-comparison.html I think this one would better look like list of major features with os comparison, like: = Networking = * IPv6: major support, best stack around. * SCTP: full kernel implementation, still no userland support (i.e. ssh doesn't work over sctp by default yet). = Data storage = * ZFS: full support, datasets, compression, dedup, other stuff. Linux has LVM (?features...) and btrfs (?unstable.. ?features..), Windows has dynamic disks since XP (?features). = SMP = * (?something about comparing other shedulers with SCHED_ULE), (?some rt stuff), (?some comparison with other interesting shedulers, like DragonflyBSD and QNX). If that page would be updated at least monthly giving fair comparison with other os'es it could serve a big pros list for preferring FreeBSD over other systems. -- 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: PHORONIX: OpenCL, GLSL Back-End For LLVM May Soon Open Up
By the beginning of this year Pathscale introduced a kind of compiler capable of HMPP, a very smart model like OpenMP. This compiler seems not to be ready by now and I never got access to a beta version to test whether it was capable of compiling CUDA ready code. As far as I know, HMPP is also an open standard. Well, conclusively, there seems no real solution to be present for FreeBSD by now (as I mentioned, the Linuxulator is no real alternative due to its 32bit limitations). Christopher Bergström of PathScale offered to serve as an advocate for release of portions of PathScale's code so that it could be used in FreeBSD [1]. Did anyone take him up on it? I'd think that negotiations of this sort would be of interest to the FreeBSD Foundation and other parties. [1] http://lists.freebsd.org/pipermail/freebsd-questions/2011-June/231181.html ___ 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
AW: AW: Panic with 9.0 Beta 1 (arcmsr.c)
Hi, I updated to todays current (Beta2) and it still doesn't work - the controller doesn't find any disk. I uploaded a new dmesg/pciconf an uname-output. http://ugrohnwaldt.web02.lando.us/FBSD/dmesg-2011-08-30.log http://ugrohnwaldt.web02.lando.us/FBSD/pciconf-2011-08-30.log http://ugrohnwaldt.web02.lando.us/FBSD/uname-2011-08-30.log Moreover I send an email to Areca-support. They investigate the problem Best Regards, Uwe -Ursprüngliche Nachricht- Von: Xin LI [mailto:delp...@delphij.net] Gesendet: Montag, 29. August 2011 06:51 An: Uwe Grohnwaldt Cc: freebsd-current@freebsd.org Betreff: Re: AW: Panic with 9.0 Beta 1 (arcmsr.c) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/24/11 08:18, Uwe Grohnwaldt wrote: After this messages there are no visible disks. A camcontrol rescan all leads tot he same timeouts. Is this problem still persist after updating to at least r224905? -Ursprüngliche Nachricht- Von: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- curr...@freebsd.org] Im Auftrag von Uwe Grohnwaldt Gesendet: Mittwoch, 24. August 2011 16:37 An: freebsd-current@freebsd.org Betreff: AW: Panic with 9.0 Beta 1 (arcmsr.c) Hi, I upgraded a fresh RELENG_8_2 to CURRENT and nearly everything works fine. I only have to wait about 3 minutes during boot. In dmesg I have many messages like this: arcmsr1: scsi id 17 lun 0 cmd=0x12 srb='0xff8462bd9780' ccb command time out! http://ugrohnwaldt.web02.lando.us/FBSD/dmesg-2011-08-24.log.txt Thanks, Uwe -Ursprüngliche Nachricht- Von: John Baldwin [mailto:j...@freebsd.org] Gesendet: Dienstag, 23. August 2011 13:43 An: freebsd-current@freebsd.org Cc: Uwe Grohnwaldt Betreff: Re: Panic with 9.0 Beta 1 (arcmsr.c) On Tuesday, August 23, 2011 6:57:45 am Uwe Grohnwaldt wrote: Hi, i tried to install FBSD 9.0 beta 1. Booting the install-cd stopped with a kernel panic: panic: _mtx_lock_sleep: recursed on non-recursive mutex arcmsr Q buffer lock @ /usr/src/sys/dev/arcmsr/arcmsr.c:2093 A screenshot from the panic can be found here: http://ugrohnwaldt.web02.lando.us/FBSD/arcmsr.png Looks like this was fixed after BETA1 was released. -- John Baldwin ___ 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 - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOWxqzAAoJEATO+BI/yjfB7cUIAMOXPk+d3nG830gG8B/GyT02 Wd1h+V2nkqACz6+cYoX8xul4w6AGKh/+NPWFOGcyPC4F2yt3SA7bI7Wa/8P3Is0X Y3/kHYp2hR1f9L02O7yf8IY5ZwRIkhPCZmWc7DX2Aw31HF6Z1sNHkVCSbhTHqCvN vBuz5UnAlnKPWif789QnFMYa0B9LmWoDN8gDPjcpckWCeBr8NL9XQxxiY8ZebQYJ JMC55eG2ugxf4FOkhQFtpikBxEG5pvFuHmBhGENCFm0Y2eUOyEetjMhoqO1MA8je yhnrL1RIGc0Gax+ocrmkh60YLP7l8FQaib69imhtazYIhgrGhsv/HgP+ZWcKkGs= =nZDu -END PGP SIGNATURE- ___ 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
AW: AW: AW: Panic with 9.0 Beta 1 (arcmsr.c)
Hi, yes. quote Dear Sir/Madam, we will download the OS and arrange a machine to check this issue. Best Regards, /quote I offered them to test it directly on my machine, because our storage isn't at production level at the moment. quote Dear Sir/Madam, thank you for your support, i will let you know if we need your assist. Best Regards, /quote Cheers, Uwe -Ursprüngliche Nachricht- Von: Xin LI [mailto:delp...@delphij.net] Gesendet: Dienstag, 30. August 2011 00:21 An: Uwe Grohnwaldt Betreff: Re: AW: AW: Panic with 9.0 Beta 1 (arcmsr.c) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/29/11 15:20, Uwe Grohnwaldt wrote: Hi, I updated to todays current (Beta2) and it still doesn't work - the controller doesn't find any disk. I uploaded a new dmesg/pciconf an uname-output. http://ugrohnwaldt.web02.lando.us/FBSD/dmesg-2011-08-30.log http://ugrohnwaldt.web02.lando.us/FBSD/pciconf-2011-08-30.log http://ugrohnwaldt.web02.lando.us/FBSD/uname-2011-08-30.log Moreover I send an email to Areca-support. They investigate the problem So you got their reply already? Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOXBDMAAoJEATO+BI/yjfBwUQIAIptQ3xAOMEa/iq8S+iRpDfy nE6jjL9VAjUC1TjqsjKs+MRw4KV8KV4lUMuyo/qcWaeDp24RCjW22taVrZl9vEdM 5Q7pyH3EgbRRXO8d5GXDt8q707U27eW/j61ORsugU5Zts2tbyrQHUTWiR8ADo2f/ E6sa712wRUT9z2oc6L+BumP7QDZ78+FvjfxYMDnoM1t8t+1AsuL/BU+MeywPTua3 vUSGZYSe6skFau5eimu+bO4o4Q+Kz2u3rmCC7L7uD1s7hfenw7FB1OroVF0DqJSq 0xpBX43l10W0SHTUypfj5bnHLax3DCVwTDoo1OGGHWPlrBboRM2Uo0xiYQfmBaU= =qgyk -END PGP SIGNATURE- ___ 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: NFS mountd version 3 over TCP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 08/29/11 11:47, Rick Macklem wrote: I think it did. Lookup of .. was failing. I think that was because ni_strictrelative (added for capabilities) wasn't initialized and happened to be non-zero. Please try this patch and let us know if it helps: That fixed it, thanks! Thanks for reporting this, I'm not sure when these fields not being initialized would have been noticed otherwise, rick No problem, thanks for the quick response. If I see any other issues I'll be sure to report them. Steve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBAgAGBQJOXBlDAAoJEPXPYrMgexuhWzQH/AjTSRYzw93cn78BXwOpUVKJ nS22ZH/fFdW6Jvaa/Ph1xHj6P04zjOlIrxTEIEnQvDlWKJkdnG/JwIuvOKFHmyiu VpFBDReTNSPO3wN2t3pAOz89Kfs3mVkY1AvFly5RJ+CmZAzo/zafamS0UHICIm49 wSDb/KDo+hkEF+5Iluqsbm453wU0PiDjmPhlkvuFtGkn7kuuoU2r+inBFT5AzYlO 1iX79uKRJEywcaVFBbL4QiEVG6w/SWI+mUIy+TZmfAtaQGSQMJ2sEpGlcYSSzZ8E 4BLf9C2BPE+IWR8ssw1eF99+W39yCszpaauXhgwX1Tjrv/Ae0PBDONd4H1ejekQ= =T0ct -END PGP SIGNATURE- ___ 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: kqueue and device driver experience anyone ?
Luigi Rizzo wrote this message on Fri, Aug 26, 2011 at 23:01 +0200: The other thing i need (but i believe i know how to handle it) is tell whether .f_event() is called by KNOTE() or by kqueue_scan(), but i believe i can use the hint argument to tell the two. Why do you need to know the difference? kqueue is a level triggered API, and so should behave the same if it is called from KNOTE or kqueue_scan... The reason it is called from kqueue_scan is to ensure that the condition (level) still exists, and to get updated data information (like how many bytes are available for reading)... -- 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: kqueue and device driver experience anyone ?
On Mon, Aug 29, 2011 at 05:23:15PM -0700, John-Mark Gurney wrote: Luigi Rizzo wrote this message on Fri, Aug 26, 2011 at 23:01 +0200: The other thing i need (but i believe i know how to handle it) is tell whether .f_event() is called by KNOTE() or by kqueue_scan(), but i believe i can use the hint argument to tell the two. Why do you need to know the difference? kqueue is a level triggered because i want to control what gets executed in the lower and upper half of the kernel, for two reasons: - livelock/interrupt mitigation control. I want the bottom half to be as lightweight as possible so that the system does not get overwhelmed by incoming interrupts. - reduced locking overhead. If the bottom half only notifies that 'something happened', it does not need to bother locking device specific data structures. For things like netmap this is especially useful because some data structures are shared between kernel and userland and the only way to protect access is make sure that the kernel only plays with them when it is in the upper half. cheers luigi ___ 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
