Re: Stale mount on disconnected device: how to delete it?
On Tue, 18 Dec 2007, [EMAIL PROTECTED] wrote: Unfortunately, they do happen fairly often, usually caused by USB-related stuff (FreeBSD's USB stack is _the_ worst I've seen lately -- I take it that the stack's favorite hobby is panicking the kernel with unrivaled efficiency), sometimes by ATA/ATAPI/SATA (interestingly, SCSI code is quite stable), someimes by something obscure (e.g., just exiting qbittorrent kills the kernel -- NFS woes maybe? just an example). Hot-swapping with some ATA and SCSI drivers is impossible, too (result in panics). == apparently i'm not the only one who had to disable EHCI in order to get ACPI working on a laptop. i'm not a kernel hacker, but how those two are related isn't obvious to me. OHCI works fine, usually ;) -- ...atom http://atom.smasher.org/ 762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808 - "The law does not allow me to testify on any aspect of the National Security Agency, even to the Senate Intelligence Committee." -- General Allen, Director of the NSA, 1975 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD specific WINE errors
On Tue, Dec 18, 2007 at 01:32:06PM -0500, [EMAIL PROTECTED] wrote: > Recently eve-online came out with a new client. Since they now have a > "linux" version (which uses TransGaming's Cedega) they are less > concerned with wine compatiblity. That said, it seems that some wise > people have it working on linux, and I have downloaded, patched and > compiled they code they're using. > > However, the new eve code chucks the following errors on FreeBSD: > > err:iphlpapi:getRouteTable Received unsupported sockaddr family 0x12 > err:iphlpapi:getRouteTable Unexpected address type 0x10 > err:iphlpapi:getRouteTable Unexpected address type 0x20 sockaddr family 0x12 (18) is defined in include/sys/socket.h as: #define AF_LINK 18 /* Link layer interface */ I'm completely unfamiliar with Wine (although I am an EVE player! :D ), but my guess is that the Linux EVE client is trying to do something like get a list of IP addresses bound to an interface, or something low-level in the routing table. It's possible that the emulation layer in Wine for FreeBSD lacks this translation. As for the other errors, I'm not sure... -- | 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]"
FreeBSD specific WINE errors
Recently eve-online came out with a new client. Since they now have a
"linux" version (which uses TransGaming's Cedega) they are less
concerned with wine compatiblity. That said, it seems that some wise
people have it working on linux, and I have downloaded, patched and
compiled they code they're using.
However, the new eve code chucks the following errors on FreeBSD:
err:iphlpapi:getRouteTable Received unsupported sockaddr family 0x12
err:iphlpapi:getRouteTable Unexpected address type 0x10
err:iphlpapi:getRouteTable Unexpected address type 0x20
err:ole:CoGetClassObject class {9a5ea990-3034-4d6f-9128-01f3c61022bc} not
registered
err:ole:CoGetClassObject no class object {9a5ea990-3034-4d6f-9128-01f3c61022bc}
could be created for context 0x1
I was hoping some FreeBSD wizards here might recognise what is going
wrong here. I'm not sure about the ole object (of if it's important),
but the iphlpapi calls --- which I think are the initial http requests
that get game news --- are failing and possibly freebsd specific.
Dave.
--
|David Gilbert, Independent Contractor. | Two things can be |
|Mail: [EMAIL PROTECTED]| equal if and only if they |
|http://daveg.ca | are precisely opposite. |
=GLO
___
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?
> > 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 ;) > > Off the top of my head, what is wrong/hard with just logging a device > failure, discarding all remaining cached operations, and unmounting > the fs when a disk device goes missing? I understand that this is not > a viable solution for critical filesystems, but I can see nothing > wrong with this approach for removable devices and/or non-critical > fs's. I was wondering that myself. The possibility of losing data (after some timeout, of course) sure as heck beats recovering from the annoying panicks when something happens with the filesystem's underlying device. And who said those panicks are no problem for production systems? My workstation is a "production system", and it is very hard to recover from reboots in general, and crashes in particular. Unfortunately, they do happen fairly often, usually caused by USB-related stuff (FreeBSD's USB stack is _the_ worst I've seen lately -- I take it that the stack's favorite hobby is panicking the kernel with unrivaled efficiency), sometimes by ATA/ATAPI/SATA (interestingly, SCSI code is quite stable), someimes by something obscure (e.g., just exiting qbittorrent kills the kernel -- NFS woes maybe? just an example). Hot-swapping with some ATA and SCSI drivers is impossible, too (result in panics). I hope you don't mind me, an ol' whiner here, too much, but I really had to say that FreeBSD used to be far more stable. So it seems the trade-off "stability->features" could not be avoided... > Comment: Nikos Ntarmos <[EMAIL PROTECTED]> [SorAlx] ridin' VS1400 ___ 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 Tue, 18 Dec 2007, Nikos Ntarmos wrote: > Off the top of my head, what is wrong/hard with just logging a device > failure, discarding all remaining cached operations, and unmounting > the fs when a disk device goes missing? I understand that this is not > a viable solution for critical filesystems, but I can see nothing > wrong with this approach for removable devices and/or non-critical > fs's. There was a long, long thread which discussed this earlier. It's easy to say what should be done, it's harder to submit patches that clean up the respective failure modes. -- 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 18, 2007 at 01:13:55AM +0100, Romain Tartière wrote: > 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 ;) Off the top of my head, what is wrong/hard with just logging a device failure, discarding all remaining cached operations, and unmounting the fs when a disk device goes missing? I understand that this is not a viable solution for critical filesystems, but I can see nothing wrong with this approach for removable devices and/or non-critical fs's. Just my $0.02. \n\n -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Nikos Ntarmos <[EMAIL PROTECTED]> iD8DBQFHZ2ABm6J1ac+VFgoRAhWtAJ4uomUoe0IDVG0qG2W+t7y9ZSMjugCbBAoz LtIIMhMCk9iZ3NeStO8uwLU= =+o7j -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: questions on development(7)
Hi, Sorry for the late reply. On Fri, Nov 09, 2007 at 04:56:24AM +, Aryeh M. Friedman wrote: > 4. Mergemaster behaves strange now: everytime I run it does a > buildworld before doing the merge (even if I just did a > installworld)... also it seems to default this to /usr/src2 (which is > most of the time what I want)... is this normal? and if so how do I > turn it off and if I can't how do I set which source tree to use? This is because you're using -m /usr/src2 instead -m /usr/src2/etc. mergemaster(8) isn't well documented for this point. I've written a PR about this and Ruslan Ermilov pointed out he already submitted a better solution to this problem nearly two years ago. Mine: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/118536 Ruslan's: http://www.freebsd.org/cgi/query-pr.cgi?pr=96528 Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
