Hi, For a few weeks now, when I drag my mouse over some text with the left button pressed down, the selection will reproducibly abort after a second or so and start re-selecting even though I never let go of the mouse button. This used to work fine and is very annoying, to say the least. Is anybody else seeing this? It happens both on the console and in X. I'm running moused like this: /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid dmesg output: ums0: <vendo...

Did you try both: /dev/unlpt0 and /dev/ulpt0 ? --HPS _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

This looks a bit like an issue I'm about to start chasing where FS devices fed through a HS hub disconnect "spontaneously" under load. It doesn't look like it but to be sure there are no hubs between the host and the printer? Sam _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Le Fri, 3 Jul 2009 17:56:54 +0200, No, it returns # usbconfig -u 0 -a 2 reset usbconfig: could not reset device: Input/output error Then ulpt detaches ulpt0: at uhub0, port 1, addr 2 (disconnected) Yes, after the first job: # usbconfig -u 0 -a 2 dump_curr_config_desc ugen0.2: <product 0x001a vendor 0x04f9> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0020 bNumInterfa...

ntp.conf update from 2009/06/07 is very welcome, works great straight out of the box, much better than before! many thanks to whoever worked on this. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any m...

amd64, svn HEAD 195136 June 28, 2009 What enables /dev/ufs and /dev/ufsid? Below /usr is labeled yet /dev/ufs and /dev/ufsid are empty. geom label is loaded. [root@esata /usr/home/james]# tunefs -p /usr tunefs: ACLs: (-a) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks p...

This fixes the panic for me. Loading drm module either at loader prompt or compiling it in both works with your patch. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Yes, if some file that was in that directory is still open (or mmap'd and the process hasn't yet exit()'d), it will exist as a file named ".nfsXXX" until the v_usecount goes to 0 and then it's removed, which would explain Afraid not. NFSv4 has an Open, but it is an open share lock and not a POSIX style open, so NFSv4 clients still do the silly rename. (ie. The NFSv4 Remove Op is defined as removing the file and not just unlinking it and the NFSv4 server isn't required to retain the file after remo...

I want to make some points clear to avoid a confusion and spread of FUD. It seems we have at least three issues, all different: 1. Syscalls slowdown on amd64. To see this, you need to microbenchmark syscall enter/leave sequence. I doubt that it can be seen on any load except while (1) {getpid();} loops or such. The issue is valid _only_ for amd64. I developed the patch with the input from Jeff who confirmed that this slowdown is solved by the change. 2. There are enough independent ...

_______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

I think this is related to the recent problem described in "panic on acpi_cpu_c1()" thread[1]. There is at least one patch and two workarounds (load drm module after boot or set hw.drm.msi=0 at loader prompt). _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

I have applied your patch to r195303 (which still panics as before when unpatched). The panic I previously got with my amd64 based system does not occur anymore, so the problem seems to be solved. I do not have an i386 system with MSI available to test the patch. Kind regards, Hans _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@fr...

At first, I thought something was a miss speed wise, but it looks like this hardware is either having issues, or something is wrong in general as its the same no matter which driver is used. Usually the speeds are much quicker than whats below on block writes Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- ...

Something about this particular disk perhaps 0[i7]# dd if=/dev/ad4 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 14.933896 secs (70214497 bytes/sec) Using a different seagate disk, 0[i7]# dd if=/dev/ad6 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 7.542932 secs (139014377 bytes/sec) 0[i7]# I will re-run the tests with the newer seagate. Perhaps a firmware update to the 'slow' ...

Sorry, I just opened up the case to confirm, and it is indeed a SATA DVD drive. ---Mike _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

Sorry again for the confusion. I am trying a *different* motherboard (INTEL DX58SO) and drive now with your 0629 patch as well as the diff below. --- ahci.c.prev 2009-06-29 12:48:45.000000000 +0300 +++ ahci.c 2009-06-29 17:25:29.000000000 +0300 @@ -986,7 +986,7 @@ ahci_begin_transaction(device_t dev, uni if (ch->slot[tag].state == AHCI_SLOT_EMPTY) break; } while (tag != ch->lastslot); - if (tag == ch->lastslot) + i...

We dont have too many disk I/O bound apps here. Where we do, we typically have used raid controllers in RAID10. But I will experiment a little more over the weekend. For us, we are interested in large amounts of storage for backup purposes. Having things like port multiplier features are very nice to have. But I will try some Looking in the BIOS, I am able to toggle IDE and RAID mode only for the eSata controller portion, where as I have IDE, AHCI and RAID for the onboard Intel cont...

You're almost there... I did this a while ago, can't remember when, but I just upgraded the system that had this from FreeBSD 6.3 of sometime in 2006 to 7.2. What I believe I did from this point on was: Copy everything from the root partition to mirror/root. Modify /etc/fstab to mount root on mirror/root. Reboot. Now the original root partition isn't mounted anymore, so we can do operate on it's geom stuff. gmirror insert root da0p2 That should be it. If that doesn't work you ca...