Re: MPSAFE VFS -- List of upcoming actions
Sorry fo the delay. About the ntfs support, I'd go with fuse and leave the most relevant filesystems in kernel space. In fact filesystems not particulary specific and not tied our kernel would go to userspace; thinks like smbfs, nwfs, ntfs, ext2 o ext4 for example should be in userspace (the list is incomplete and I don't really know if all of them are yet implemenent in userspace) in my opinion. That would make them easier to maintain (changes in the kernel would only affect fuse, once fixed all the userspace filesystem would work again). As a bonus, we would get many working fs based on fuse. In the server side gluster is a desirable thing; in the desktop things like gvfs (in the linux world gvfs is used not only by gnome but also by kde or xfce) or truecrypt I'm fixing low hanging fruit for the moment (see r238411 for example) and I still have to make a throughful review. However my idea is to commit the support once: - ntfs-3g is well stress-tested and proves to be bug-free - there is no major/big technical issue pending after the reviews I'm now looking for people sticking with the branch and trying to stress-test ntfs-3g as much as they can. For example I know that Gustau (cc'ed) already had issues. It would be good if he tries to reproduce them and make a full report. I've seen ntfs-3g+fuse crashing a few times and IIRC most of the time the problem happened while unmounting the filesystem. I don't have the core dump files at hand, so I'll try to fix gnn patches to compile with my recent current (it doesn't compile, time ago I fixed fuse but I guess those patches wouldn't be enough right now) and try to panic the machine. When I do I'll do full reports of the panics. As final note, George as agreed to maintain FUSE in the long-term and of course I'll give him an hand as time permits. Any moment you need help needed coding, testing, etc let me know. Thanks, Attilio -- --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ 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: MPSAFE VFS -- List of upcoming actions
2012/7/18, Gustau Pérez i Querol : > > Sorry fo the delay. > > About the ntfs support, I'd go with fuse and leave the most relevant > filesystems in kernel space. In fact filesystems not particulary > specific and not tied our kernel would go to userspace; thinks like > smbfs, nwfs, ntfs, ext2 o ext4 for example should be in userspace (the > list is incomplete and I don't really know if all of them are yet > implemenent in userspace) in my opinion. That would make them easier to > maintain (changes in the kernel would only affect fuse, once fixed all > the userspace filesystem would work again). > > As a bonus, we would get many working fs based on fuse. In the > server side gluster is a desirable thing; in the desktop things like > gvfs (in the linux world gvfs is used not only by gnome but also by kde > or xfce) or truecrypt I'm really concerned also about ntfs and smbfs at the moment. It seems that there is also a FUSE smbfs port, but I never used it and I'm not sure about its state at all. >> >> I'm fixing low hanging fruit for the moment (see r238411 for example) >> and I still have to make a throughful review. >> However my idea is to commit the support once: >> - ntfs-3g is well stress-tested and proves to be bug-free >> - there is no major/big technical issue pending after the reviews >> >> I'm now looking for people sticking with the branch and trying to >> stress-test ntfs-3g as much as they can. For example I know that >> Gustau (cc'ed) already had issues. It would be good if he tries to >> reproduce them and make a full report. > > I've seen ntfs-3g+fuse crashing a few times and IIRC most of the > time the problem happened while unmounting the filesystem. The FUSE module you had testing still has several bugs. You can try this patch: http://people.freebsd.org/~attilio/fuse_AW_DONE_ISDOTDOT_collision.patch on top of the FUSE branch I'm working on: svn://svn.freebsd.org/base/projects/fuse/ however it still doesn't address the cloning races (I'm rewriting it in order to take advantage of devfs_*_devpriv() interface right now). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: MPSAFE VFS -- List of upcoming actions
On 07/17/2012 22:54, Gustau Pérez i Querol wrote: > In fact filesystems not particulary specific and not tied our kernel > would go to userspace; thinks like smbfs, nwfs, ntfs, ext2 o ext4 for > example should be in userspace A big -1 here. The more native FS support we have the better off we are in terms of both people migrating from other OS', and people who need to maintain compatibility with other OS'. Personally I use both msdosfs and ext2fs extensively for the latter purpose, and would not want to see either removed. Doug -- Change is hard. ___ 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: system hangs on shutdown while on wireless (ath) (Was: drm2 and the kernel messages on shutdown)
Ruslan Mahmatkhanov wrote on 18.06.2012 13:10: Ivan Klymenko wrote on 18.06.2012 13:02: В Mon, 18 Jun 2012 12:35:33 +0400 Ruslan Mahmatkhanov пишет: Good day, since switching to new drm code (starting at April if I recall correctly) I'm experiencing sporadic laptop hangs when choose the shutdown command in UI (gnome) environment. The hdd led isn't blinking but the laptop is still up. In such cases I forced to shutdown it by pressing power off button, but at the next system start it running filesystem checks (yes, with journal but some time only full fsck is able to fix that). What I'm asking for is - when there some sysctl or boot loader option will be available to turn on kernel messages on shutdown? I really want to know on what it hanging on. I didn't bothered with this while it was available as third-party patch, but since it is now in -current and enabled by default, I think this feature should be available. Thanks. PS. I'm now subscribed to current@. So do not need to approve my previous message, that's waiting for moderator approval. Dear Ruslan. Your problems hang your laptop is not associated with the transition to drm2. And you can see this - when the downgrade to the SVN revision r236313 Your problems are now committing to this http://svnweb.freebsd.org/base?view=revision&revision=236317 You can check it and make sure my right. Good luck Thanks Ivan, I'll check it out. But the request in subject line is still valid for me, because the current state make me feels like.. uhmm.. a blind kitten :) Hi, I still didn't tried to revert this change to check if it the reason. But I realized that I only got this issue when I'm on wireless. And I can 100% reproduce this. When using ethernet (re) - system shuts down just fine. When using wireless (ath) - it hanging forever. So it seems like ath deadlock or something (cc:ing Adrian). Would you please provide me with instructions on how to debug this, or what info should I provide to you to realize this. Thanks. ath0@pci0:37:0:0: class=0x028000 card=0x1461103c chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR9285 Wireless Network Adapter (PCI-Express)' class = network My -current is from Sat Jul 14 12:15:20 2012 (svn #238449). -- Regards, Ruslan Tinderboxing kills... the drives. ___ 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"
Comparison of the nfse compatibility mode with mountd and exports(5)
On Sat, Jun 30, 2012 at 08:53:09PM -0400, Rick Macklem wrote: > I haven't looked at Andrey's patch, but conceptually it sounds like > the best approach. As I understand it, the problem with replacing > mountd with nfse (at least in the FreeBSD source tree) is that nfse > is not 100% backwards compatible with /etc/exports and, as such, is > a POLA violation. Since NFSE was mentioned in this thread and there were some opinions about its compatibility with existent NFS exports configuration, I made comparison of the nfse compatibility mode with mountd and exports(5): http://nfse.sourceforge.net/COMPATIBILITY ___ 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: MPSAFE VFS -- List of upcoming actions
On 07/17/2012 22:54, Gustau Pérez i Querol wrote: In fact filesystems not particulary specific and not tied our kernel would go to userspace; thinks like smbfs, nwfs, ntfs, ext2 o ext4 for example should be in userspace The list is incomplete and maybe wrong; maybe some should stay in the kernel. It was just a quick guess. If you are think the list should be reviewed, I completely agree. A big -1 here. The more native FS support we have the better off we are in terms of both people migrating from other OS', and people who need to maintain compatibility with other OS'. Well, I don't think we would lose compatibility (but I may be wrong). I think there are some fs' too complex to implement or maintain, like the ntfs one. About the ntfs case there's a complete fs implementation of it in userspace. And there are also many other fs' implementations in userspace. I think we can benefit from those implementations, removing the burden of maintaining them in the kernel (it would have been useful to have it in userspace right now because of the vfs giant lock removal deadline). The fs' staying in the kernel should be well maintained, the others in userspace would always work too as long as fuse is up to date; if anything changes in the kernel only fuse would need to be fixed to allow the many fs' in userpace to work. In the final situation we would end having a few fs in the kernel (I don't exactly know which ones to keep) and then some in userspace that could be installed via ports. We wouldn't lose compatibility with other OS', I think instead we would have more compatibility because we could benefit from the implementation of many fs' in userspace. People migrating from other OS' would have the possibility of installing the appropriate fusefs port. Of course, I don't know the exact list of fs' staying and leaving. Personally I use both msdosfs and ext2fs extensively for the latter purpose, and would not want to see either removed. Well, I don't know which ones I would remove/migrate to userspace. The msdosfs is probably one I wouldn't migrate. About the ext2 I used to use it time ago at work. Now I remember there was a GoC in 2009 to update the implementation and I would keep it in the kernel. We could even keep ext2 in the kernel and have support for it as a fusefs port; I could choose the kernel or the userspace implementation. At work I also have to deal with ext4 or exfat filesystems from time to time. Having a working fuse implementation would allow me to have a better compatibility with other OS'. -- --- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona ___ 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: system hangs on shutdown while on wireless (ath) (Was: drm2 and the kernel messages on shutdown)
Hm, find the revision where I committed the PCIe powersave fixes to ath_hal/ar9002/ar9285_attach.c and undo them? See if that has any effect? adrian On 18 July 2012 02:57, Ruslan Mahmatkhanov wrote: > Ruslan Mahmatkhanov wrote on 18.06.2012 13:10: >> >> Ivan Klymenko wrote on 18.06.2012 13:02: >>> >>> В Mon, 18 Jun 2012 12:35:33 +0400 >>> Ruslan Mahmatkhanov пишет: >>> Good day, since switching to new drm code (starting at April if I recall correctly) I'm experiencing sporadic laptop hangs when choose the shutdown command in UI (gnome) environment. The hdd led isn't blinking but the laptop is still up. In such cases I forced to shutdown it by pressing power off button, but at the next system start it running filesystem checks (yes, with journal but some time only full fsck is able to fix that). What I'm asking for is - when there some sysctl or boot loader option will be available to turn on kernel messages on shutdown? I really want to know on what it hanging on. I didn't bothered with this while it was available as third-party patch, but since it is now in -current and enabled by default, I think this feature should be available. Thanks. PS. I'm now subscribed to current@. So do not need to approve my previous message, that's waiting for moderator approval. >>> >>> Dear Ruslan. >>> Your problems hang your laptop is not associated with the transition to >>> drm2. >>> And you can see this - when the downgrade to the SVN revision r236313 >>> >>> Your problems are now committing to this >>> http://svnweb.freebsd.org/base?view=revision&revision=236317 >>> >>> You can check it and make sure my right. >>> >>> Good luck >> >> >> Thanks Ivan, I'll check it out. But the request in subject line is >> still valid for me, because the current state make me feels like.. >> uhmm.. a blind kitten :) > > > Hi, I still didn't tried to revert this change to check if it the reason. > But I realized that I only got this issue when I'm on wireless. And I can > 100% reproduce this. When using ethernet (re) - system shuts down just fine. > When using wireless (ath) - it hanging forever. > > So it seems like ath deadlock or something (cc:ing Adrian). Would you please > provide me with instructions on how to debug this, or what info should I > provide to you to realize this. Thanks. > > ath0@pci0:37:0:0: class=0x028000 card=0x1461103c chip=0x002b168c > rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR9285 Wireless Network Adapter (PCI-Express)' > class = network > > My -current is from Sat Jul 14 12:15:20 2012 (svn #238449). > > -- > Regards, > Ruslan > > Tinderboxing kills... the drives. > > ___ 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"
IPod crash seen with FreeBSD only
Hi, I have one of those locked down silvery IPod's, and wanted to try out gnupod to get some MP3's transferred to the device. I made it once, but then my luck ended :-) Anyway I found what looks like a remote crash vulnerability in the IPod firmware. How to make it crash: 1) Plug USB cable and wait for /dev/daX device to appear. 2) mount -t msdosfs /dev/daX /mnt 3) rm -rf /mnt/* 4) umount /mnt 5) Now unplug the USB cable and wait for the device to boot into menu mode. Don't press any keys. 6) Then plug the USB cable again into the PC/Lapop running FreeBSD 8/9. 7) Observation: The device goes into an infinite reboot loop until the USB cable is unplugged. 8) How to recover your device: 9) Add this quirk: usbconfig add_dev_quirk_vplh 0x05ac 0x1262 0 65535 UQ_MSC_NO_SYNC_CACHE ^^ vendor ^^ product Please write down the iProduct and iVendor before testing this, else you will have to plug your device into a Linux/Mac box to get it back. You can do this by running the following command before executing any of the steps above: usbconfig -d X.Y dump_device_desc 10) Plug your device. 11) /dev/daX should appear again :-) Phhh :-) This is the dmesg you see when the device is crashing. usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) usb_alloc_device: Failure selecting configuration index 0:USB_ERR_STALLED, port 2, addr 3 (ignored) ugen7.3: at usbus7 ugen7.3: at usbus7 (disconnected) If Apple could explain this, would be great! I believe some Apple people are hanging around on these lists :-) --HPS BTW: Does anyone have any howtos regarding using more recent ipod devices with FreeBSD ? Or Does anyone know how to get the old ones with more flash maybe, which can run rockbox ? ___ 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: MPSAFE VFS -- List of upcoming actions
On Tue, Jul 17, 2012 at 10:54 PM, Gustau Pérez i Querol wrote: > >Sorry fo the delay. > >About the ntfs support, I'd go with fuse and leave the most relevant > filesystems in kernel space. In fact filesystems not particulary specific > and not tied our kernel would go to userspace; thinks like smbfs, nwfs, > ntfs, ext2 o ext4 for example should be in userspace (the list is incomplete > and I don't really know if all of them are yet implemenent in userspace) in > my opinion. That would make them easier to maintain (changes in the kernel > would only affect fuse, once fixed all the userspace filesystem would work > again). > >As a bonus, we would get many working fs based on fuse. In the server > side gluster is a desirable thing; in the desktop things like gvfs (in the > linux world gvfs is used not only by gnome but also by kde or xfce) or > truecrypt > > >> >> I'm fixing low hanging fruit for the moment (see r238411 for example) >> and I still have to make a throughful review. >> However my idea is to commit the support once: >> - ntfs-3g is well stress-tested and proves to be bug-free >> - there is no major/big technical issue pending after the reviews >> >> I'm now looking for people sticking with the branch and trying to >> stress-test ntfs-3g as much as they can. For example I know that >> Gustau (cc'ed) already had issues. It would be good if he tries to >> reproduce them and make a full report. > > >I've seen ntfs-3g+fuse crashing a few times and IIRC most of the time the > problem happened while unmounting the filesystem. I can reliably crash a system by doing an rsync to an ntfs-3g mounted FS. I have simply stopped doing it an have spent no time trying to track down the problem, but maybe anyone (gnn?) working on fusefs might want to try it. FWIW, I can to "rsync -avn local-path/ remote-system:ntfs-3g/path" always works. Remove the 'n' and actually move the data and it dies. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: IPod crash seen with FreeBSD only
On Wed, Jul 18, 2012 at 2:22 PM, Hans Petter Selasky wrote: > Hi, > > I have one of those locked down silvery IPod's, and wanted to try out gnupod > to get some MP3's transferred to the device. I made it once, but then my luck > ended :-) Anyway I found what looks like a remote crash vulnerability in the > IPod firmware. How to make it crash: > > 1) Plug USB cable and wait for /dev/daX device to appear. > 2) mount -t msdosfs /dev/daX /mnt > 3) rm -rf /mnt/* > 4) umount /mnt > 5) Now unplug the USB cable and wait for the device to boot into menu mode. > Don't press any keys. > 6) Then plug the USB cable again into the PC/Lapop running FreeBSD 8/9. > > 7) Observation: The device goes into an infinite reboot loop until the USB > cable is unplugged. > > 8) How to recover your device: > 9) Add this quirk: > > usbconfig add_dev_quirk_vplh 0x05ac 0x1262 0 65535 UQ_MSC_NO_SYNC_CACHE > ^^ vendor ^^ product > > Please write down the iProduct and iVendor before testing this, else you will > have to plug your device into a Linux/Mac box to get it back. You can do this > by running the following command before executing any of the steps above: > > usbconfig -d X.Y dump_device_desc > > 10) Plug your device. > 11) /dev/daX should appear again :-) Phhh :-) > > This is the dmesg you see when the device is crashing. > > usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) > usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) > usb_alloc_device: Failure selecting configuration index 0:USB_ERR_STALLED, > port 2, addr 3 (ignored) > ugen7.3: at usbus7 > ugen7.3: at usbus7 (disconnected) > > If Apple could explain this, would be great! I believe some Apple people are > hanging around on these lists :-) Been meaning to mention this... I run into this regularly as of a couple months ago with my iPod classic as well (I used to use my FreeBSD workstation as a "charger" for my iPod). I'll provide more details if I get a chance. Thanks, -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: VIA VE-900 nano X2 boot failure
In muc.lists.freebsd.current, you wrote: > On 17 July 2012 20:56, Felix Kohtz wrote: >> I recently purchased a VIA EPIA-VE-900 Nano X2 1,4 GHz Dual Core MiniITX >> Board >> http://www.via.com.tw/en/products/viamainboards/ve900/index.jsp >> >> and wanted to install FreeBSD (amd64) from an iso-file on it. >> >> I tried to install: >> >> FreeBSD 8.3-RELEASE : >> works fine. >> dmesg here: http://pastebay.net/1068207 >> >> FreeBSD 9.0-RELEASE : >> stops during boot-process. >> (part of - where it stops) dmesg here: http://pastebay.net/1068208 >> >> FreeBSD 9.1-RELENG_9-20120716-JPSNAP from >> https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/ >> stops during boot-process at same point like 9.0-RELEASE. >> >> FreeBSD 10.0-HEAD-20120717-JPSNAP from >> https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/ >> stops during boot-process at same point like 9.0-RELEASE. >> >> I can provide more information on this problem if you say me what is needed >> and i offer to test changes. > > To get better diagnostics: > 1) try to put hint.hdac.0.disabled="1" into your /boot/device.hints, > to disabled hdac device, then reboot and see if that helps > hdac is under a cloud, since it is included in GENERIC starting from 9.0. > 2) boot kernel in verbose mode > (boot_verbose="YES" in /boot/loader.conf or simply boot -v) Seems like a couple of Via boards are affected, see http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/163164 I had to rebuild the kernel to get it booting because hint.hdac.0.disabled="1" didn't work on 9.0-REL btw HTH ___ 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"
