Re: version hwpmc kernel module & pmc library not match
check with cpuid: Vendor ID: "GenuineIntel"; CPUID level 10 Intel-specific functions: Version 06f7: Type 0 - Original OEM Family 6 - Pentium Pro Model 15 - Extended model 0 Stepping 7 Reserved 0 Extended brand string: "Intel(R) Xeon(R) CPU E5335 @ 2.00GHz" CLFLUSH instruction cache line size: 8 Hyper threading siblings: 4 > Check ports 'cpuid' - > > > Vendor ID: "GenuineIntel"; CPUID level 10 > > Intel-specific functions: > Version 06f6: > Type 0 - Original OEM > Family 6 - Pentium Pro > Model 15 - > Extended model 0 > Stepping 6 > Reserved 0 > > > Odds are you have a post-P4 Intel processor. > > -Kip > > > On Dec 17, 2007 7:47 PM, binto <[EMAIL PROTECTED]> wrote: >> Hi, >> >> i run command for kernel profiling purpose: >> >> pmcstat -S instructions -O /tmp/sample.out >> >> and i get error: >> pmcstat: ERROR: Initialization of the pmc(3) library failed: No such >> file >> or directory >> >> I've compile my FreeBSD 6.3-PRERELEASE kernel in i386 machine : >> device hwpmc >> options HWPMC_HOOKS >> >> myquestion: >> - any suggestion to fix that error? >> - how to find what version number of the hwpmc in my machine? >> - does pmc have version too? >> >> Thanks >> Binto >> >> >> >> ___ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to >> "[EMAIL PROTECTED]" >> > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: version hwpmc kernel module & pmc library not match
Check ports 'cpuid' - Vendor ID: "GenuineIntel"; CPUID level 10 Intel-specific functions: Version 06f6: Type 0 - Original OEM Family 6 - Pentium Pro Model 15 - Extended model 0 Stepping 6 Reserved 0 Odds are you have a post-P4 Intel processor. -Kip On Dec 17, 2007 7:47 PM, binto <[EMAIL PROTECTED]> wrote: > Hi, > > i run command for kernel profiling purpose: > > pmcstat -S instructions -O /tmp/sample.out > > and i get error: > pmcstat: ERROR: Initialization of the pmc(3) library failed: No such file > or directory > > I've compile my FreeBSD 6.3-PRERELEASE kernel in i386 machine : > device hwpmc > options HWPMC_HOOKS > > myquestion: > - any suggestion to fix that error? > - how to find what version number of the hwpmc in my machine? > - does pmc have version too? > > Thanks > Binto > > > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
version hwpmc kernel module & pmc library not match
Hi, i run command for kernel profiling purpose: pmcstat -S instructions -O /tmp/sample.out and i get error: pmcstat: ERROR: Initialization of the pmc(3) library failed: No such file or directory I've compile my FreeBSD 6.3-PRERELEASE kernel in i386 machine : device hwpmc options HWPMC_HOOKS myquestion: - any suggestion to fix that error? - how to find what version number of the hwpmc in my machine? - does pmc have version too? Thanks Binto ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux version of libusb that works with FreeBSD
On Mon, 17 Dec 2007, Mike Meyer wrote: > On Mon, 17 Dec 2007 16:26:58 +1030 "Daniel O'Connor" <[EMAIL PROTECTED]> wrote: > > I am wondering if anyone has tried building such a beast? > > ie a Lunux libusb that will be able to access devices in FreeBSD.. > > Well, the devel/libusb port builds out of the box for me. It's used > by a number of image grabbing tools (gphoto, sane and hplib), and by > tools like nut for talking to UPS systems. I want a *Linux* version of libusb that works on a FreeBSD box under emulation. I have a piece of software for which I can't obtain the source that accesses USB devices with libusb. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Stale mount on disconnected device: how to delete it?
Hi Antony, On Tue, Dec 18, 2007 at 09:36:19AM +1100, Antony Mawer wrote : > Every time this comes up it's branded with the "really hard to fix" > message, but I seem to recall the last time this came up Matt Dillon > chimed in and said he'd managed to fix it in Dragonfly without too > much pain. > > I had a browse back a while ago at the commits on DF to try and > pinpoint the changes that were required to see how practical they were > to bring across to FreeBSD; I don't profess to be an expert and have > yet to investigate the changes in any detail, but these were the > commits I identified: > > http://freshbsd.org/2007/06/14/03/55/27 > http://freshbsd.org/2007/06/17/06/08/52 > http://freshbsd.org/2007/06/14/02/09/30 > http://freshbsd.org/2007/06/13/21/58/38 > http://freshbsd.org/2007/06/13/21/53/39 > > If someone else is interested in looking at this, it may provide a > useful starting point... First of all, I am not a FreeBSD kernel hacker and thus maybe I am wrong but I think that it is important to recall that DragonflyBSD is ``the logical continuation of the FreeBSD 4.x series'' [1]. As so, it does not provides geom(8) [2], AFAIK. While geom(8) is a really cool piece of code, it also adds many abstraction layers that may have to be adapted to handle such an abnormal situation. This might explain why nobody has already [tried to] fixed this. Maybe somebody from geom@ can give us further details or correct what I wrote? Best regards, Romain References: 1. http://www.dragonflybsd.org/about/history.shtml 2. http://www.freebsd.org/cgi/man.cgi?query=geom -- Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgpva5rpBwUc5.pgp Description: PGP signature
Re: Stale mount on disconnected device: how to delete it?
On Mon, Dec 17, 2007 at 10:32:48AM -0800, Yuri wrote : > In case of USB device (which device in question in this problem > happens to be) usbd can be used to mount it. > > If attach/detach events trigger mount/unmount commands this problem > shouldn't exist. I didn't try though. The problem is that the detach event can be caught only too late to unmount the device properly. How may it be possible to sync a disk ``as soon as it is detached'' (that is when it is not physically connected to the computer anymore)? Mounting the disk read-only may be a workaround, just as not caching writes (default behaviour of some versions of Windows) and syncing the disk all the time, but this is not as reliable as the mount system provided by Unix and Unix like operating systems. AFAICR, this is the sole weakness of the FreeBSD operating system I know :) And since it is, according to me, an operator error, the best we can do is to use the system as it was designed for ;) Regards, Romain -- Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgpBUSS4BarH9.pgp Description: PGP signature
Re: Stale mount on disconnected device: how to delete it?
On 18/12/2007 5:09 AM, Peter Jeremy wrote: On Mon, Dec 17, 2007 at 03:07:02AM -0800, Yuri wrote: I had USB camera connected and recognized as umass0 and mounted as /mnt/camera on /dev/da0s1. Camera was disconnected while it was still mounted. This triggers known and extremely painful to fix bugs in FreeBSD. Your best work-around is to use ports/emulators/mtools rather than mount_msdosfs to to access removable devices. Every time this comes up it's branded with the "really hard to fix" message, but I seem to recall the last time this came up Matt Dillon chimed in and said he'd managed to fix it in Dragonfly without too much pain. I had a browse back a while ago at the commits on DF to try and pinpoint the changes that were required to see how practical they were to bring across to FreeBSD; I don't profess to be an expert and have yet to investigate the changes in any detail, but these were the commits I identified: http://freshbsd.org/2007/06/14/03/55/27 http://freshbsd.org/2007/06/17/06/08/52 http://freshbsd.org/2007/06/14/02/09/30 http://freshbsd.org/2007/06/13/21/58/38 http://freshbsd.org/2007/06/13/21/53/39 If someone else is interested in looking at this, it may provide a useful starting point... --Antony ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kqueue and libev
Kip Macy wrote: Do you have a set of regression tests for libev? It sounds like they would worth having to regression test kqueue. I would have thought that libevent and libev should both the checked against kqueue. Also APR and everything else that has support. I'm not the author of libev though, so I'm the wrong guy to ask. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Large array in KVM
On Friday 07 December 2007 06:23:51 am Jeremy Chadwick wrote: > On Fri, Dec 07, 2007 at 10:43:00AM +0100, Gerald Heinig wrote: > > Hi Sonja, > > > > > Hi everyone. > > > > > > I'm working on a kernel module that needs to maintain a large > > structure > > > in memory. As this structure could grow too big to be stored in > > memory, > > > it would be good to offload parts of it to the disk. What would be the > > > best way to do this? Could using a memory-mapped file help? > > > > How about implementing your code as a system call, which is called from > > a process that maps a large file into memory, as you suggested above. > > I presume you'd have to handle the question of whether or not your pages > > are in memory yourself, ie. pretty much like any other system call. > > > > Interesting question. > > Somewhat related question: > > What purpose does SYSCALL_MODULE(9) serve? I attempted to use this last > month while writing a kernel module of my own, and was never able to get > it to work for (what understood to be) a couple different reasons: > > 1) There's a maximum # of syscalls permitted (see SYS_MAXSYSCALL in > include/sys/sycall.h), which means a dynamically-allocated syscall via > SYSCALL_MODULE(9) cannot be inserted into the syscalls list. > > 2) The example code in share/examples/kld/syscall/module/syscall.c > specifies the sysent offset as NO_SYSCALL (e.g. -1). You can't pick an > arbitrary number here (from what I could tell), because the kernel > explicitly ensures that the syscall number being called is not larger > than SYS_MAXSYSCALL. This forces you to "steal" a syscall number > between 1 and SYS_MAXSYSCALL, no? -1 tells the kernel to find an unused syscall vector (there are several reserved for this purpose) and assign it for you. You then read the assigned number in userland using modstat(). (You can also get it from your 'offset' variable.. the kernel modifies it in the SYSINIT() invoked by SYSCALL_MODULE() and you could export it via a sysctl, etc.) > 3) I tried using a syscall number (115, deprecated vtrace), using it as > the offset when calling SYSCALL_MODULE, but the userland program calling > syscall(2) returned an error. I didn't research this too thoroughly. syscall_register() will only overwrite a system call whose function pointer is set to lkmnosys() or lkmressys(). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kqueue and libev
On Dec 17, 2007 1:25 PM, James Mansion <[EMAIL PROTECTED]> wrote: > Kip Macy wrote: > >> he's just plain misinforme > > Until we know what he is referring to we can't actually say that. > > -Kip > > > > OK he said I could post from our private email so here goes. There were > bits in and around relating to the > Solaris /dev/poll support (and the mechanism's limitations) which I've > elided. > > I think the most telling thing is probably that drivers need to provide > support and that a single mechanism > in the driver doesn't support select and poll at the same time - which I > guess lines up with the reported failure > with USB serial. > > Does kqueue work with USB for example? How about an AIO request to read > from a USB endpoint? > > It may well just be a case of 'fessing up to system limitations. > > James > > > > Compile and install rxvt-unicode on freebsd and run it with: > >urxvt # works, uses select (or maybe poll) >LIBEV_FLAGS=8 urxvt # acts weird, uses kqueue > >(note: only works when urxvt isn't set[gu]id) > > The typical symptoms are either delayed notificatrions, no notifications at > all or _continuous_ notifications and read failing with EAGAIN. Here is a > ktrace showing the latter: > http://ue.tst.eu/45eb8a3c3e812933cbe3172af2ee4a6c.txt > > kqueue works well with sockets (or with about anything on netbsd), but > fails on more exotic types such as ptys. (I test on Freebsd 6.2 RELEASE, > but got reports about problems with earlier and later versions, too, > as well as on openbsd (which I didn't verify) and on darwin (which is > completely broken)). > > > > You normally don't get useful writeable/readable state for files, > > > No, I only want the same readyness notifications as with select or poll, > as is documented in the manpage. (even on platforms where kqueue works > this requires some heuristics and workarounds with kqueue due to design > limitations (for example problems with close() or fork() that force > constant rearming), but thats common in interfaces like kqueue, and by now > well understood and handled by libev). > > > > Actually, until recently it was broken on pipes. We've never received > > any PRs to that effect so there is no way of knowing. You'll have > > better luck asking the author himself. To be more precise, this only manifested itself in erlang. > > Well, one should better document the types with which it works (which on > freebsd apparently includes sockets and nothing else). I also think one > should rethink the internal design if every driver needs its own kqueue > support, as that will always force kqueue into a second-class citizen not > suitable as replacement for select, as it's unreasonable to expect kqueue > to just work when its so little used and requires such a high maintainance > (linux' epoll for example works fine with everything because it doesn't > require drivers to support epoll specifically, so it is unlikely that > epoll fails when select would work for example, which is the case on > freebsd and darwin). > > The fact that it works fine on everything I threw at it on netbsd is > probably not the result of better design, but more better maintainance, so > I wouldn't be surprised if some future version of netbsd failed in similar > ways (OTOH, in the past, netbsd consistently was the less buggy platform > regardless of topic, wether it was threads, ptys or kqueue, so I might get > quite disappointed if that happened :) Interesting, that has been completely counter to my experience. However, I rely on a completely different set of subsystems. Do you have a set of regression tests for libev? It sounds like they would worth having to regression test kqueue. Thanks for your feedback. -Kip ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kqueue and libev
Kip Macy wrote: he's just plain misinforme Until we know what he is referring to we can't actually say that. -Kip OK he said I could post from our private email so here goes. There were bits in and around relating to the Solaris /dev/poll support (and the mechanism's limitations) which I've elided. I think the most telling thing is probably that drivers need to provide support and that a single mechanism in the driver doesn't support select and poll at the same time - which I guess lines up with the reported failure with USB serial. Does kqueue work with USB for example? How about an AIO request to read from a USB endpoint? It may well just be a case of 'fessing up to system limitations. James Compile and install rxvt-unicode on freebsd and run it with: urxvt # works, uses select (or maybe poll) LIBEV_FLAGS=8 urxvt # acts weird, uses kqueue (note: only works when urxvt isn't set[gu]id) The typical symptoms are either delayed notificatrions, no notifications at all or _continuous_ notifications and read failing with EAGAIN. Here is a ktrace showing the latter: http://ue.tst.eu/45eb8a3c3e812933cbe3172af2ee4a6c.txt kqueue works well with sockets (or with about anything on netbsd), but fails on more exotic types such as ptys. (I test on Freebsd 6.2 RELEASE, but got reports about problems with earlier and later versions, too, as well as on openbsd (which I didn't verify) and on darwin (which is completely broken)). You normally don't get useful writeable/readable state for files, No, I only want the same readyness notifications as with select or poll, as is documented in the manpage. (even on platforms where kqueue works this requires some heuristics and workarounds with kqueue due to design limitations (for example problems with close() or fork() that force constant rearming), but thats common in interfaces like kqueue, and by now well understood and handled by libev). Actually, until recently it was broken on pipes. We've never received any PRs to that effect so there is no way of knowing. You'll have better luck asking the author himself. Well, one should better document the types with which it works (which on freebsd apparently includes sockets and nothing else). I also think one should rethink the internal design if every driver needs its own kqueue support, as that will always force kqueue into a second-class citizen not suitable as replacement for select, as it's unreasonable to expect kqueue to just work when its so little used and requires such a high maintainance (linux' epoll for example works fine with everything because it doesn't require drivers to support epoll specifically, so it is unlikely that epoll fails when select would work for example, which is the case on freebsd and darwin). The fact that it works fine on everything I threw at it on netbsd is probably not the result of better design, but more better maintainance, so I wouldn't be surprised if some future version of netbsd failed in similar ways (OTOH, in the past, netbsd consistently was the less buggy platform regardless of topic, wether it was threads, ptys or kqueue, so I might get quite disappointed if that happened :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stale mount on disconnected device: how to delete it?
> I had USB camera connected and recognized as umass0 and mounted as > /mnt/camera > on /dev/da0s1. > > Camera was disconnected while it was still mounted. I submitted this late at night. Now in the morning another solution came to my mind. I thought I will find it in replies but I didn't. In case of USB device (which device in question in this problem happens to be) usbd can be used to mount it. If attach/detach events trigger mount/unmount commands this problem shouldn't exist. I didn't try though. Otherwise for non-USB devices this situation probably can only happen in case of failing devices. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stale mount on disconnected device: how to delete it?
On Mon, Dec 17, 2007 at 03:07:02AM -0800, Yuri wrote: >I had USB camera connected and recognized as umass0 and mounted as /mnt/camera >on /dev/da0s1. > >Camera was disconnected while it was still mounted. This triggers known and extremely painful to fix bugs in FreeBSD. Your best work-around is to use ports/emulators/mtools rather than mount_msdosfs to to access removable devices. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpRNb81cJxRx.pgp Description: PGP signature
Re: Disk sync at shutdown and fusefs filesystems
On Mon, 17 Dec 2007 17:41:16 +0100 Csaba Henk <[EMAIL PROTECTED]> wrote: > [This message has also been posted to gmane.os.freebsd.devel.hackers.] > On 2007-12-17, Alejandro Pulver <[EMAIL PROTECTED]> wrote: > > > > - Some "got hung in unmount" issues are to be sorted out (these > >appeared on Linux, and they might or might not appear on FreeBSD). > > > > > > IIRC you are saying that any user could make umount hang. And you said > > this is an unintended behavior caused by the implementation, which > > appeared on Linux and we don't know if it will happen on FreeBSD. > > > > Otherwise the daemon would synchronize the fs and let umount return > > normally, and this wouldn't happen, right? > > > > If this always happens then what is the difference between happening on > > a root/non-root mount, as it will hang anyways? > > > > If I missed the point again please correct me, and clarify the following: > > Does the hang (point 2)/umount stuck (point 3) issues consist of the > > same (I assumed so)? If not, please point out the differences. > > Oh sorry, I see my wording was still not clear enough... > > Point 3) and point 2) are completely different issues. > > Point 2) is about a _bug_ which might make unmount hang (contrary to our > intentions). Point 3) is about the access control _policy_ of the > "mounting with sync unmount" feature which is DOS capable: it enables > some malicious code to make the shutdown sequence hung. > I understand now (about 3). So a user could write a FUSE daemon which never replies properly (or doesn't reply at all) to the DESTROY code, and the kernel module would be waiting indefinitely. Stalling the shutdown sequence. Maybe this could be solved with a timeout (see below). > [Btw, I used/use the "hang", "block", "make stuck" expressions > interchangeably, I'm sorry if it's not correct English or just sounds > unnaturally in some cases.] > I'm not a native English speaker, so these all seemed the same to me. Thanks for the clarifications. > > The same statement with more details: > > Point 2) is about a defect of a naive, straightforward implementation of > handling the DESTROY message in the FUSE library. That is, if the daemon > is mounted with synch umount, under certain circumstances (if I > understood correctly, this amounts to killing the daemon with a SIGTERM [ie., > the FUSE session terminates due the sigterm and not because of doing an > unmount(2) on the fs]) the umount code of the lib falls into an infinite > loop. This is a bug which may or may not affect FreeBSD once DESTROY is > implemented for it -- the umount code in the lib is platform specific, > anyway. So this is just about a possible bug which really falls into > the "we will see it when we get there" category. > O.K. > OTOH, by the essence of the synch umount, mounting an fs daemon w/ synch > umount means that the daemon gets the control over the termination > of the unmount syscall. So being able to mount w/ synch umount assumes > some kind of trusted state -- it enables a malicious daemon to block its > unmounting. It's not a real risk if the unmount is done manually -- when > the person who unmounts the fs observes that the daemon is blocking the > unmount, she can turn to either a forced unmount or killing the daemon. > However, during the shutdown sequence, which is automated, noone will be > there to forcedly terminate the FUSE session, and shutdown might get > stuck this way. > > So we have to decide how to control the access to mounting with synch > umount. This is point 3). > I can see 2 approaches to solving this (not sure if both are possible though): Maybe adding a timeout to the FUSE kernel module? I've seen the syncer daemon say "giving up on ..." when I had ATA errors related to configuration/cable problems (it retried for a while, and as disk couldn't sync, it terminated anyways). So maybe something similar could be implemented. Otherwise IMHO only root should be allowed to do such mounts, or having a sysctl disabled by default to allow users do this (like vfs.usermount). > > Probably I just provide an implementation of it for the kernel module > and add a "sync_umount" option to mount_fusefs(8) and let it be as is > and we'll see how well it works out, and what to do about access control > -wise. > > Csaba When the implementation is ready, and if these problems are sorted out, do you think it could be enabled by default (at least for root)? Because that's the behavior most filesystems would prefer I think. Best Regards, Ale signature.asc Description: PGP signature
Re: Disk sync at shutdown and fusefs filesystems
On 2007-12-17, Alejandro Pulver <[EMAIL PROTECTED]> wrote: > > - Some "got hung in unmount" issues are to be sorted out (these >appeared on Linux, and they might or might not appear on FreeBSD). > > > IIRC you are saying that any user could make umount hang. And you said > this is an unintended behavior caused by the implementation, which > appeared on Linux and we don't know if it will happen on FreeBSD. > > Otherwise the daemon would synchronize the fs and let umount return > normally, and this wouldn't happen, right? > > If this always happens then what is the difference between happening on > a root/non-root mount, as it will hang anyways? > > If I missed the point again please correct me, and clarify the following: > Does the hang (point 2)/umount stuck (point 3) issues consist of the > same (I assumed so)? If not, please point out the differences. Oh sorry, I see my wording was still not clear enough... Point 3) and point 2) are completely different issues. Point 2) is about a _bug_ which might make unmount hang (contrary to our intentions). Point 3) is about the access control _policy_ of the "mounting with sync unmount" feature which is DOS capable: it enables some malicious code to make the shutdown sequence hung. [Btw, I used/use the "hang", "block", "make stuck" expressions interchangeably, I'm sorry if it's not correct English or just sounds unnaturally in some cases.] The same statement with more details: Point 2) is about a defect of a naive, straightforward implementation of handling the DESTROY message in the FUSE library. That is, if the daemon is mounted with synch umount, under certain circumstances (if I understood correctly, this amounts to killing the daemon with a SIGTERM [ie., the FUSE session terminates due the sigterm and not because of doing an unmount(2) on the fs]) the umount code of the lib falls into an infinite loop. This is a bug which may or may not affect FreeBSD once DESTROY is implemented for it -- the umount code in the lib is platform specific, anyway. So this is just about a possible bug which really falls into the "we will see it when we get there" category. OTOH, by the essence of the synch umount, mounting an fs daemon w/ synch umount means that the daemon gets the control over the termination of the unmount syscall. So being able to mount w/ synch umount assumes some kind of trusted state -- it enables a malicious daemon to block its unmounting. It's not a real risk if the unmount is done manually -- when the person who unmounts the fs observes that the daemon is blocking the unmount, she can turn to either a forced unmount or killing the daemon. However, during the shutdown sequence, which is automated, noone will be there to forcedly terminate the FUSE session, and shutdown might get stuck this way. So we have to decide how to control the access to mounting with synch umount. This is point 3). Probably I just provide an implementation of it for the kernel module and add a "sync_umount" option to mount_fusefs(8) and let it be as is and we'll see how well it works out, and what to do about access control -wise. Csaba ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Stale mount on disconnected device: how to delete it?
> >On Mon, Dec 17, 2007 at 03:07:02AM -0800, Yuri wrote : >> I had USB camera connected and recognized as umass0 and mounted as >> /mnt/camera >> on /dev/da0s1. >> >> Camera was disconnected while it was still mounted. > >Personal recipe when this kind of things happens (generally caused by a >camera switching to power-save mode or that runs out of battery): Would not umount -f do the trick? -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stale mount on disconnected device: how to delete it?
On Mon, Dec 17, 2007 at 08:58:27AM -0600, Sergey Babkin wrote : > Would not umount -f do the trick? I tried it without particular care one time on a failing device and experienced an instant system reboot (was it caused by the faulty disk or by a limitation in the implementation of the system (FreeBSD 5.x at that time), I can't be sure). Since then, I have never tried to force the unmounting of any device in favor of rebooting the system. In fact, crawling the PR database already reports problems about forcing unmounting of devices [kern/77026, kern/102250, usb/46176, ...]. So I prefer to be sure that everything is safe (not mounted read/write) before trying anything that can lead to data loss. Regards, Romain -- Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgpDS21Ap1THE.pgp Description: PGP signature
Re: Linux version of libusb that works with FreeBSD
Quoting Daniel O'Connor <[EMAIL PROTECTED]> (from Mon, 17 Dec 2007 21:39:39 +1030): On Mon, 17 Dec 2007, Alexander Leidinger wrote: AFAIR HPS' USB stack has linux compatibility, maybe you should ask him / have a look at it. I had a look at the code but I can't see any Linux related code. You better ask him, I never used his USB stack, I just remembered to have read something like this... HPS CCed. Bye, Alexander. -- People need good lies. There are too many bad ones. -- Bokonon, "Cat's Cradle" by Kurt Vonnegut, Jr. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: boot0 code mystery
On Mon, Dec 17, 2007 at 07:16:02PM +0530, M.Girish Rao wrote: > Whats the memory location of start? I'm going off of memory of my old x86 days, so be kind to me. :-) By the look of it, it's BOOT_BOOT0_ORG, which is 0x600. I'm basing this on the flags passed to cc (actually ld) during linktime. > what's this for incb -0xe(%di) ? No idea. > where are we jumping to in jmp main-LOAD+ORIGIN? main is below the jmp main-LOAD+ORIGIN jump: 91 incb -0xe(%di) # Sector number 92 jmp main-LOAD+ORIGIN# To relocated code 93 94 main: 95 #if defined(SIO) && COMSPEED != 0 LOAD is set to 0x7c00: 27 .set LOAD,0x7c00# Load address You should be able to get the offset of main by looking at boot0.o once assembled. The start origin doesn't appear to be included (which is why it's added manually). eos# objdump -t boot0.o | grep 'main$' 0022 l .text main Thus I'm left to believe main-LOAD+ORIGIN == 0x8a22. This can be verified by doing: eos# objdump -S -M addr16,data16 boot0.o | grep -m 1 'jmp' 1f: e9 00 8ajmp8a22 > whats ORIGIN? ORIGIN is an assembler variable set to 0x600: 25 .set ORIGIN,0x600 # Execution address -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stale mount on disconnected device: how to delete it?
Hi On Mon, Dec 17, 2007 at 03:07:02AM -0800, Yuri wrote : > I had USB camera connected and recognized as umass0 and mounted as /mnt/camera > on /dev/da0s1. > > Camera was disconnected while it was still mounted. Personal recipe when this kind of things happens (generally caused by a camera switching to power-save mode or that runs out of battery): - switch to single user mode - unmount everything that can be unmounted - remount ro everything that can't be unmounted - reboot (and generally enjoy a kernel panic ;-) ) Not suited for critical production servers, but you won't connect a camera on such a system, would you? BTW, their are already a couple PR around there: http://www.freebsd.org/cgi/query-pr-summary.cgi?text=umount Regards, Romain -- Romain Tartière <[EMAIL PROTECTED]>http://romain.blogreen.org/ pgp: 8DAB A124 0DA4 7024 F82A E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgpgz2OjsuCCE.pgp Description: PGP signature
boot0 code mystery
Hi, I am reading the code for boot0 (/usr/src/sys/boot/i386/boot0/boot0.S). This is the part i am trying to understand: /* * Initialise segments and registers to known values. * segments start at 0. * The stack is immediately below the address we were loaded to. */ start: cld # String ops inc xorw %ax,%ax# Zero movw %ax,%es# Address movw %ax,%ds# data movw %ax,%ss# Set up movw $LOAD,%sp # stack /* * Copy this code to the address it was linked for */ movw %sp,%si# Source movw $start,%di # Destination movw $0x100,%cx # Word count rep # Relocate movsw # code /* * Set address for variable space beyond code, and clear it. * Notice that this is also used to point to the values embedded in the block, * by using negative offsets. */ movw %di,%bp# Address variables movb $0x8,%cl # Words to clear rep # Zero stosw # them /* * Relocate to the new copy of the code. */ incb -0xe(%di) # Sector number jmp main-LOAD+ORIGIN# To relocated code This is all the information I could gather: From this first disk's first sector, 512 bytes are read into the memory location of 0x7C00. After that, the BIOS will check for the number 0xAA55 at the memory location of 0x7DFE (the last two bytes of the boot block code). After the boot0 program is loaded and control is transferred to it, it will set up its registers and stack information. Then, boot0 relocates itself into a lower memory location and jumps to the new address offset to its main routine. Whats the memory location of start? what's this for incb -0xe(%di) ? where are we jumping to in jmp main-LOAD+ORIGIN? whats ORIGIN? I would really appreciate if some could kindly help me out with this. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Stale mount on disconnected device: how to delete it?
Yuri wrote: I had USB camera connected and recognized as umass0 and mounted as /mnt/camera on /dev/da0s1. Camera was disconnected while it was still mounted. I've understood that the only solution to this currently is "don't do that then". :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux version of libusb that works with FreeBSD
Quoting Daniel O'Connor <[EMAIL PROTECTED]> (from Mon, 17 Dec 2007 16:26:58 +1030): I am wondering if anyone has tried building such a beast? ie a Lunux libusb that will be able to access devices in FreeBSD.. The reason I'd like it is that I want to use this http://rmdir.de/~michael/xilinx/ in FreeBSD so I can talk to a USB JTAG cable. The thing I am not sure about is how ioctl's would get mangled on the way through. They get interpreted as linux ioctl, as they are handled by the linuxulator. You could try to write a wrapper there... I guess the other approach would be to use a standard Linux libusb but emulate the device tree it uses in Linux.. Would be a lot of work though I think. As long as you can specify the devices in the linux app, it's enough to translate the ioctl's. Apart from that, there's some kind of translation layer for devices already, but I don't know if it just a Linux major/minor -> FreeBSD dev mapping, or if you can map linux dev -> FreeBSD dev. AFAIR HPS' USB stack has linux compatibility, maybe you should ask him / have a look at it. Bye, Alexander. -- Power is poison. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Stale mount on disconnected device: how to delete it?
I had USB camera connected and recognized as umass0 and mounted as /mnt/camera on /dev/da0s1. Camera was disconnected while it was still mounted. Now 'mount' command shows: /dev/da0s1 on /mnt/camera (msdosfs, local) 'umount /dev/da0s1' command tells that device is not configured correctly. 'umount -f /dev/da0s1' causes the system to hang. And when I try to reconnect the camera it shows up as /dev/da1s1. How to delete stale mount and stale device? Should I file a PR for this system hang? I use 7.0-BETA4. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux version of libusb that works with FreeBSD
On Mon, 17 Dec 2007, Alexander Leidinger wrote: > > The thing I am not sure about is how ioctl's would get mangled on > > the way through. > > They get interpreted as linux ioctl, as they are handled by the > linuxulator. You could try to write a wrapper there... Yeah.. Maybe an FS approach would be simpler since there is already a framework. > > I guess the other approach would be to use a standard Linux libusb > > but emulate the device tree it uses in Linux.. Would be a lot of > > work though I think. > > As long as you can specify the devices in the linux app, it's enough > to translate the ioctl's. Apart from that, there's some kind of > translation layer for devices already, but I don't know if it just a > Linux major/minor -> FreeBSD dev mapping, or if you can map linux dev > -> FreeBSD dev. Not sure I can specify the devices, but there's always ln :) > AFAIR HPS' USB stack has linux compatibility, maybe you should ask > him / have a look at it. I had a look at the code but I can't see any Linux related code. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
