Re: pkg 1.4 freeze please test test test!
On Sat, 1 Nov 2014 23:45:49 +0100 Baptiste Daroussin b...@freebsd.org wrote: On Sat, Nov 01, 2014 at 04:13:32PM +0100, Marc UBM wrote: [snip] The update is failing for me with: .../usr/ports/ports-mgmt/pkg-devel# make all install clean === Installing for pkg-1.4.0.a3 === Checking if pkg already installed pkg-static: sqlite error while executing DROP INDEX packages_unique;CREATE UNIQUE INDEX packages_unique ON packages(name); in file pkgdb.c:2246: UNIQUE constraint failed: packages.name *** Error code 74 Stop. make[1]: stopped in /usr/ports/ports-mgmt/pkg-devel *** Error code 1 Stop. make: stopped in /usr/ports/ports-mgmt/pkg-devel portmaster fails with: root@ubm:/usr/ports/ports-mgmt/pkg-devel# portmaster -d pkg === No ORIGIN in /var/db/pkg/pkgconf-0.9.7/+CONTENTS === Cannot continue === Aborting update === Killing background jobs Terminated === Exiting make.conf related options: #enable pkgng (might be superfluous) WITH_PKGNG=yes #enable PKGNG devel WITH_PKGNG=devel Am I doing something wrong? You are doing nothing wrong but that probably means you have ancient packages that never got upgraded (in the old time it was allowed to have 2 packages installed with the same name) we have fixed that over the time and that is why we had unicity set to origin as a hack for a while, we are now moving to unique name so you have to make sure that all your installed packages are up to date before moving to new pkg. At least make sure you do not have 2 packages with the same name. Concerning portmaster I have no idea why it now thinks you are not using pkg :( I checked for packages with the same name and found none (via pkg version). Meanwhile, the upgrade still fails for me. Has anybody got any new ideas? Thanks in advance! Regards, Marc ___ 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: Problem with ebook reader on usb
On Sun, 8 Dec 2013 22:54:25 +0100 Marc UBM Bocklet ubm.free...@gmail.com wrote: On Sun, 8 Dec 2013 22:44:33 +0100 Marc UBM Bocklet ubm.free...@gmail.com wrote: Hiho! :-) I got myself a new ebook reader (Onyx M92), but encountered a strange problem when connecting it to my freebsd machine. Shortly after mounting it, the device gets disconnected (causing the mounted storage to disappear). There is no such behavior with Windows 7. uname -a: FreeBSD xxx 11.0-CURRENT FreeBSD 11.0-CURRENT #11 r258254M: Sun Nov 17 13:38:01 CET 2013 xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP amd64 Following up: With FreeBSD xxx 11.0-CURRENT FreeBSD 11.0-CURRENT #16 r258254:259095M: Sun Dec 15 08:53:22 CET 2013 xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP amd64 the problem has disappeared. Bye Marc ___ 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: SVN commit 259045 breaks -CURRENT
On Sun, 15 Dec 2013 08:43:22 +0200 Konstantin Belousov kostik...@gmail.com wrote: On Sat, Dec 14, 2013 at 09:56:04PM -0800, Steve Kargl wrote: On Sun, Dec 15, 2013 at 07:47:22AM +0200, Konstantin Belousov wrote: On Sat, Dec 14, 2013 at 02:16:27PM -0800, Steve Kargl wrote: On Sat, Dec 14, 2013 at 11:11:15PM +0100, Stefan Esser wrote: Am 14.12.2013 22:59, schrieb Steve Kargl: On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser wrote: 2) SSH logins are very slow, many seconds of delay between connect and password prompt, several seconds after password entry until a command prompt appears (normally instantaneous) Ah, so that explains the behavior I'm see. Just updated a circa Aug 3rd i386 FreeBSD to top-of-tree. My ssh logins to my work system take 30+ seconds now. :( You may want to test the attached patch, which reverts the above mentioned commit. I probably won't get to it until tomorrow, because I had started a dog-food system purge including re-installing all ports. The laptop takes a bit a time to recompile everything. Are you all running i386, compiled with gcc ? The Aug 3rd system was built with gcc. The system upgrade I did this morning is using clang. I rebuilt everything and delete old things with delete-old and delete-old-libs. A kernel built with the commit reverted has not exhibited any similar behavior during the whole day. I'll recompile again with the overflow option enabled to see if the issue returns. Bye Marc ___ 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: SVN commit 259045 breaks -CURRENT
On Sat, 14 Dec 2013 13:59:04 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser wrote: I noticed a severe slowdown and network problems on my amd64 -CURRENT system. By bisecting SVN revisions I identified the following commit to be responsible: -- r259045 | kib | 2013-12-06 22:44:13 +0100 (Fri, 06 Dec 2013) | 9 lines Disallow optimizations which potentially remove boundary checks for signed values due to a compiler authors considering integer overflow as impossible. The change follows suit of other projects taking the same measure. -- This commit added the following line to /sys/conf/kern.mk: CFLAGS+= -fno-strict-overflow The most obvious symptoms of the problem on my system are: 1) sa-spamd needs 140 seconds to start (instead of a few seconds) 2) SSH logins are very slow, many seconds of delay between connect and password prompt, several seconds after password entry until a command prompt appears (normally instantaneous) Ah, so that explains the behavior I'm see. Just updated a circa Aug 3rd i386 FreeBSD to top-of-tree. My ssh logins to my work system take 30+ seconds now. :( I observe dnsmasq causing extremely high network latency without any visible reason - though that may not be related. I'll remove -fno-strict-overflow, recompile kernel and see if anything changes. Bye Marc ___ 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: SVN commit 259045 breaks -CURRENT
On Sun, 15 Dec 2013 07:47:22 +0200 Konstantin Belousov kostik...@gmail.com wrote: On Sat, Dec 14, 2013 at 02:16:27PM -0800, Steve Kargl wrote: On Sat, Dec 14, 2013 at 11:11:15PM +0100, Stefan Esser wrote: Am 14.12.2013 22:59, schrieb Steve Kargl: On Sat, Dec 14, 2013 at 10:44:10PM +0100, Stefan Esser wrote: 2) SSH logins are very slow, many seconds of delay between connect and password prompt, several seconds after password entry until a command prompt appears (normally instantaneous) Ah, so that explains the behavior I'm see. Just updated a circa Aug 3rd i386 FreeBSD to top-of-tree. My ssh logins to my work system take 30+ seconds now. :( You may want to test the attached patch, which reverts the above mentioned commit. I probably won't get to it until tomorrow, because I had started a dog-food system purge including re-installing all ports. The laptop takes a bit a time to recompile everything. Are you all running i386, compiled with gcc ? I'm running amd64 compiled with clang; uname -a: FreeBSD xxx 11.0-CURRENT FreeBSD 11.0-CURRENT #15 r258254:259095M: Sun Dec 8 12:11:33 CET 2013 xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP amd64 I'm recompiling right now to see if maybe I'm having a different issue. Bye Marc ___ 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: svn commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken
On Mon, 9 Dec 2013 22:49:33 +0200 Aleksandr Rybalko r...@freebsd.org wrote: Hi Marc, yeah I seen same at the test board Intel Ironlake (D) SVGA controller vgapci0@pci0:0:2:0: class=0x03 card=0x00368086 chip=0x00428086 First thought was about firmware(BIOS) bug related to VGA graphic mode. Are your board made by Intel too (mine is INTEL DH55HC)? WBW -- Aleksandr Rybalko r...@freebsd.org Yeah, this is a Shuttle barebone with an Intel Board inside it: http://www.shuttle.eu/index.php?id=836L=0 dmesg is attached. Bye Marc dmesg.newcons Description: Binary data ___ 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: svn commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken
; /* TODO */
+ break;
+
+ default:
+ error = ENOIOCTL;
+ break;
+ }
+ return (error);
+}
+
+static int
+fb_read(struct cdev *dev, struct uio *uio, int ioflag)
+{
+
+ return (0); /* XXX nothing to read, yet */
+}
+
+static int
+fb_write(struct cdev *dev, struct uio *uio, int ioflag)
+{
+
+ return (0); /* XXX nothing written */
+}
+
+static int
+fb_mmap(struct cdev *dev, vm_ooffset_t offset, vm_paddr_t *paddr, int nprot,
+vm_memattr_t *memattr)
+{
+ struct fb_info *info;
+
+ info = dev-si_drv1;
+ if (offset info-fb_size) {
+ *paddr = info-fb_pbase + offset;
+ return (0);
+ }
+ return (EINVAL);
+}
+
+
+static void
+vt_fb_mem_wr1(struct fb_info *sc, uint32_t o, uint8_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ *(uint8_t *)(sc-fb_vbase + o) = v;
+}
+
+static void
+vt_fb_mem_wr2(struct fb_info *sc, uint32_t o, uint16_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ *(uint16_t *)(sc-fb_vbase + o) = v;
+}
+
+static void
+vt_fb_mem_wr4(struct fb_info *sc, uint32_t o, uint32_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ *(uint32_t *)(sc-fb_vbase + o) = v;
+}
+
+static void
+vt_fb_mem_copy(struct fb_info *sc, uint32_t offset_to, uint32_t offset_from,
+uint32_t size)
+{
+
+ memmove((void *)(sc-fb_vbase + offset_to), (void *)(sc-fb_vbase +
+ offset_from), size);
+}
+
+static void
+vt_fb_indir_wr1(struct fb_info *sc, uint32_t o, uint8_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ sc-fb_write(sc-fb_priv, o, v, 1);
+}
+
+static void
+vt_fb_indir_wr2(struct fb_info *sc, uint32_t o, uint16_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ sc-fb_write(sc-fb_priv, o, v, 2);
+}
+
+static void
+vt_fb_indir_wr4(struct fb_info *sc, uint32_t o, uint32_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ sc-fb_write(sc-fb_priv, o, v, 4);
+}
+
+static void
+vt_fb_indir_copy(struct fb_info *sc, uint32_t offset_to, uint32_t
offset_from,
+uint32_t size)
+{
+
+ sc-copy(sc-fb_priv, offset_to, offset_from, size);
+}
+
+int
+fb_probe(struct fb_info *info)
+{
+
+ if (info-fb_size == 0)
+ return (ENXIO);
+
+ if (info-fb_write != NULL) {
+ if (info-fb_write == NULL) {
+ return (EINVAL);
+ }
+ info-fb_flags |= FB_FLAG_NOMMAP;
+ info-wr1 = vt_fb_indir_wr1;
+ info-wr2 = vt_fb_indir_wr2;
+ info-wr4 = vt_fb_indir_wr4;
+ info-copy = vt_fb_indir_copy;
+ } else if (info-fb_vbase != 0) {
+ if (info-fb_pbase == 0)
+ info-fb_flags |= FB_FLAG_NOMMAP;
+ info-wr1 = vt_fb_mem_wr1;
+ info-wr2 = vt_fb_mem_wr2;
+ info-wr4 = vt_fb_mem_wr4;
+ info-copy = vt_fb_mem_copy;
+ } else
+ return (ENXIO);
+
+ return (0);
+}
+
+
+static int
+fb_init(struct fb_list_entry *entry, int unit)
+{
+ struct fb_info *info;
+
+ info = entry-fb_info;
+ entry-fb_si = make_dev(fb_cdevsw, unit, UID_ROOT, GID_WHEEL,
+ 0600, fb%d, unit);
+ entry-fb_si-si_drv1 = info;
+
+ return (0);
+}
+
+int
+fbd_list()
+{
+ struct fb_list_entry *entry;
+
+ if (LIST_EMPTY(fb_list_head))
+ return (ENOENT);
+
+ LIST_FOREACH(entry, fb_list_head, fb_list) {
+ printf(FB %s @%p\n, entry-fb_info-fb_name,
+ (void *)entry-fb_info-fb_pbase);
+ }
+
+ return (0);
+}
+
+static struct fb_list_entry *
+fbd_find(struct fb_info* info)
+{
+ struct fb_list_entry *entry, *tmp;
+
+ LIST_FOREACH_SAFE(entry, fb_list_head, fb_list, tmp) {
+ if (entry-fb_info == info) {
+ return (entry);
+ }
+ }
+
+ return (NULL);
+}
+
+int
+fbd_register(struct fb_info* info)
+{
+ struct fb_list_entry *entry;
+ int err, first;
+
+ first = 0;
+ if (LIST_EMPTY(fb_list_head))
+ first++;
+
+ entry = fbd_find(info);
+ if (entry != NULL) {
+ /* XXX Update framebuffer params */
+ return (0);
+ }
+
+ err = fb_probe(info);
+ if (err)
+ return (err);
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
--
Marc UBM Bocklet eternal@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
Re: svn commit: r259016 - in head/sys: conf dev/drm2 dev/drm2/i915 dev/drm2/radeon dev/fb dev/vt kern modules/drm2/i915kms modules/drm2/radeonkms sparc64/sparc64 sys teken
; /* TODO */
+ break;
+
+ default:
+ error = ENOIOCTL;
+ break;
+ }
+ return (error);
+}
+
+static int
+fb_read(struct cdev *dev, struct uio *uio, int ioflag)
+{
+
+ return (0); /* XXX nothing to read, yet */
+}
+
+static int
+fb_write(struct cdev *dev, struct uio *uio, int ioflag)
+{
+
+ return (0); /* XXX nothing written */
+}
+
+static int
+fb_mmap(struct cdev *dev, vm_ooffset_t offset, vm_paddr_t *paddr, int nprot,
+vm_memattr_t *memattr)
+{
+ struct fb_info *info;
+
+ info = dev-si_drv1;
+ if (offset info-fb_size) {
+ *paddr = info-fb_pbase + offset;
+ return (0);
+ }
+ return (EINVAL);
+}
+
+
+static void
+vt_fb_mem_wr1(struct fb_info *sc, uint32_t o, uint8_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ *(uint8_t *)(sc-fb_vbase + o) = v;
+}
+
+static void
+vt_fb_mem_wr2(struct fb_info *sc, uint32_t o, uint16_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ *(uint16_t *)(sc-fb_vbase + o) = v;
+}
+
+static void
+vt_fb_mem_wr4(struct fb_info *sc, uint32_t o, uint32_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ *(uint32_t *)(sc-fb_vbase + o) = v;
+}
+
+static void
+vt_fb_mem_copy(struct fb_info *sc, uint32_t offset_to, uint32_t offset_from,
+uint32_t size)
+{
+
+ memmove((void *)(sc-fb_vbase + offset_to), (void *)(sc-fb_vbase +
+ offset_from), size);
+}
+
+static void
+vt_fb_indir_wr1(struct fb_info *sc, uint32_t o, uint8_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ sc-fb_write(sc-fb_priv, o, v, 1);
+}
+
+static void
+vt_fb_indir_wr2(struct fb_info *sc, uint32_t o, uint16_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ sc-fb_write(sc-fb_priv, o, v, 2);
+}
+
+static void
+vt_fb_indir_wr4(struct fb_info *sc, uint32_t o, uint32_t v)
+{
+
+ KASSERT((o sc-fb_size), (Offset %#08x out of fb size, o));
+ sc-fb_write(sc-fb_priv, o, v, 4);
+}
+
+static void
+vt_fb_indir_copy(struct fb_info *sc, uint32_t offset_to, uint32_t
offset_from,
+uint32_t size)
+{
+
+ sc-copy(sc-fb_priv, offset_to, offset_from, size);
+}
+
+int
+fb_probe(struct fb_info *info)
+{
+
+ if (info-fb_size == 0)
+ return (ENXIO);
+
+ if (info-fb_write != NULL) {
+ if (info-fb_write == NULL) {
+ return (EINVAL);
+ }
+ info-fb_flags |= FB_FLAG_NOMMAP;
+ info-wr1 = vt_fb_indir_wr1;
+ info-wr2 = vt_fb_indir_wr2;
+ info-wr4 = vt_fb_indir_wr4;
+ info-copy = vt_fb_indir_copy;
+ } else if (info-fb_vbase != 0) {
+ if (info-fb_pbase == 0)
+ info-fb_flags |= FB_FLAG_NOMMAP;
+ info-wr1 = vt_fb_mem_wr1;
+ info-wr2 = vt_fb_mem_wr2;
+ info-wr4 = vt_fb_mem_wr4;
+ info-copy = vt_fb_mem_copy;
+ } else
+ return (ENXIO);
+
+ return (0);
+}
+
+
+static int
+fb_init(struct fb_list_entry *entry, int unit)
+{
+ struct fb_info *info;
+
+ info = entry-fb_info;
+ entry-fb_si = make_dev(fb_cdevsw, unit, UID_ROOT, GID_WHEEL,
+ 0600, fb%d, unit);
+ entry-fb_si-si_drv1 = info;
+
+ return (0);
+}
+
+int
+fbd_list()
+{
+ struct fb_list_entry *entry;
+
+ if (LIST_EMPTY(fb_list_head))
+ return (ENOENT);
+
+ LIST_FOREACH(entry, fb_list_head, fb_list) {
+ printf(FB %s @%p\n, entry-fb_info-fb_name,
+ (void *)entry-fb_info-fb_pbase);
+ }
+
+ return (0);
+}
+
+static struct fb_list_entry *
+fbd_find(struct fb_info* info)
+{
+ struct fb_list_entry *entry, *tmp;
+
+ LIST_FOREACH_SAFE(entry, fb_list_head, fb_list, tmp) {
+ if (entry-fb_info == info) {
+ return (entry);
+ }
+ }
+
+ return (NULL);
+}
+
+int
+fbd_register(struct fb_info* info)
+{
+ struct fb_list_entry *entry;
+ int err, first;
+
+ first = 0;
+ if (LIST_EMPTY(fb_list_head))
+ first++;
+
+ entry = fbd_find(info);
+ if (entry != NULL) {
+ /* XXX Update framebuffer params */
+ return (0);
+ }
+
+ err = fb_probe(info);
+ if (err)
+ return (err);
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
--
Marc UBM Bocklet eternal@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd
Problem with ebook reader on usb
Hiho! :-) I got myself a new ebook reader (Onyx M92), but encountered a strange problem when connecting it to my freebsd machine. Shortly after mounting it, the device gets disconnected (causing the mounted storage to disappear). There is no such behavior with Windows 7. uname -a: FreeBSD xxx 11.0-CURRENT FreeBSD 11.0-CURRENT #11 r258254M: Sun Nov 17 13:38:01 CET 2013 xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP amd64 The device identifies as follows: Dec 2 17:45:51 ubm kernel: ugen4.2: Linux 2.6.35.3-gd7932e6-dirty with fsl-usb2-udc at usbus4 Dec 2 17:45:51 ubm kernel: umass0: Mass Storage on usbus4 Dec 2 17:45:51 ubm kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 Dec 2 17:45:51 ubm kernel: da0: Linux File-Stor Gadget 0326 Removable Direct Access SCSI-2 device Dec 2 17:45:51 ubm kernel: da0:40.000MB/s transfers Dec 2 17:45:51 ubm kernel: da0: 3156MB (6463552 512 byte sectors: 255H 63S/T 402C) Dec 2 17:45:51 ubm kernel: da0: quirks=0x2NO_6_BYTE I tried setting (widly guessing): hw.usb.power_timeout: 30 - 0 hw.usb.no_cs_fail: 0 - 1 but to no avail. Setting hw.usb.debug: 1 yields no additional output. usbconfig dump_device_desc yields: ugen4.2: File-backed Storage Gadget Linux 2.6.35.3-gd7932e6-dirty with fsl-usb2-udc at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x0525 idProduct = 0xa4a5 bcdDevice = 0x0326 iManufacturer = 0x0001 Linux 2.6.35.3-gd7932e6-dirty with fsl-usb2-udc iProduct = 0x0002 File-backed Storage Gadget iSerialNumber = 0x0003 3230204E6F76 bNumConfigurations = 0x0001 Anybody got any ideas? :-) Bye Marc ___ 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: Problem with ebook reader on usb
On Sun, 8 Dec 2013 22:44:33 +0100 Marc UBM Bocklet ubm.free...@gmail.com wrote: Hiho! :-) I got myself a new ebook reader (Onyx M92), but encountered a strange problem when connecting it to my freebsd machine. Shortly after mounting it, the device gets disconnected (causing the mounted storage to disappear). There is no such behavior with Windows 7. uname -a: FreeBSD xxx 11.0-CURRENT FreeBSD 11.0-CURRENT #11 r258254M: Sun Nov 17 13:38:01 CET 2013 xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP amd64 The device identifies as follows: Dec 2 17:45:51 ubm kernel: ugen4.2: Linux 2.6.35.3-gd7932e6-dirty with fsl-usb2-udc at usbus4 Dec 2 17:45:51 ubm kernel: umass0: Mass Storage on usbus4 Dec 2 17:45:51 ubm kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 Dec 2 17:45:51 ubm kernel: da0: Linux File-Stor Gadget 0326 Removable Direct Access SCSI-2 device Dec 2 17:45:51 ubm kernel: da0:40.000MB/s transfers Dec 2 17:45:51 ubm kernel: da0: 3156MB (6463552 512 byte sectors: 255H 63S/T 402C) Dec 2 17:45:51 ubm kernel: da0: quirks=0x2NO_6_BYTE I tried setting (widly guessing): hw.usb.power_timeout: 30 - 0 hw.usb.no_cs_fail: 0 - 1 but to no avail. Setting hw.usb.debug: 1 yields no additional output. usbconfig dump_device_desc yields: ugen4.2: File-backed Storage Gadget Linux 2.6.35.3-gd7932e6-dirty with fsl-usb2-udc at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x0525 idProduct = 0xa4a5 bcdDevice = 0x0326 iManufacturer = 0x0001 Linux 2.6.35.3-gd7932e6-dirty with fsl-usb2-udc iProduct = 0x0002 File-backed Storage Gadget iSerialNumber = 0x0003 3230204E6F76 bNumConfigurations = 0x0001 Anybody got any ideas? :-) Some further data: the mass storage usually remains mounted if there is NO read/write activity. Read activity seems to immediately cause a disconnect. Writing behaves differently, I just managed to copy a 1.4M file onto it, it disconnected seconds after finishing. The copied file is not corrupted. Bye Marc ___ 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
sonewconn: pcb 0xfffffe001ba1d7a8: Listen queue overflow: 1 already in queue awaiting acceptance
Hiho! :-) I detected a bunch of those showing up sporadically in my log - I guess they are harmless? Jun 22 11:14:33 ubm kernel: sonewconn: pcb 0xfe0149192930: Listen queue overflow: 1 already in queue awaiting acceptance uname -a: FreeBSD xxx 10.0-CURRENT FreeBSD 10.0-CURRENT #9 r249225M: Sat Apr 20 12:03:57 CEST 2013 xxx:/usr/obj/usr/src/sys/SUBMARINE_SMP amd64 Bye Marc ___ 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
lockup with vidcontrol VESA_800x600
Hiho! :-) Yesterday I upgraded to FreeBSD hostname 9.0-CURRENT FreeBSD 9.0-CURRENT #28: Sat Jan 8 17:05:30 CET 2011 and vidcontrol VESA_800x600 stopped working (again). I exchanged emails with jkim about a similar problem in February 2010 (vidcontrol VESA_800x600 would mangle the screen output), there was no definitive resolution, but it started working again sometime around July 2010. Now however, when I try to set VESA_800x600, my machine seems to lockup. It no longer responds to any input, I cannot ping it and I cannot drop to the debugger. I've tried setting other modes, but trying to set them results in: obtaining new video mode parameters: operation not supported by device. graphics card is a: vgap...@pci0:1:0:0: class=0x03 card=0x013a1002 chip=0x514c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Radeon 8500 / 8500LE (R200)' class = display subclass = VGA Any clues what might have changed? Bye Marc -- Marc UBM Bocklet ubm.free...@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
lockup with vidcontrol VESA_800x600
Hiho! :-) Yesterday I upgraded to FreeBSD hostname 9.0-CURRENT FreeBSD 9.0-CURRENT #28: Sat Jan 8 17:05:30 CET 2011 and vidcontrol VESA_800x600 stopped working (again). I exchanged emails with jkim about a similar problem in February 2010 (vidcontrol VESA_800x600 would mangle the screen output), there was no definitive resolution, but it started working again sometime around July 2010. Now however, when I try to set VESA_800x600, my machine seems to lockup. It no longer responds to any input, I cannot ping it and I cannot drop to the debugger. I've tried setting other modes, but trying to set them results in: obtaining new video mode parameters: operation not supported by device. graphics card is a: vgap...@pci0:1:0:0: class=0x03 card=0x013a1002 chip=0x514c1002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'Radeon 8500 / 8500LE (R200)' class = display subclass = VGA Any clues what might have changed? Bye Marc -- Marc UBM Bocklet ubm.free...@gmail.com -- Marc UBM Bocklet ubm.free...@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: lockup with vidcontrol VESA_800x600
On Sun, 9 Jan 2011 11:45:52 -0500 Chris Brennan xa...@xaerolimit.net wrote: Did you try http://www.freebsdwiki.net/index.php/High_Resolution_Console? Yeah, those are the kernel settings that I've been using since approx. 2004 :-). But the wiki page yielded a new data point - trying to set MODE_280 (which corresponds to 1024x...@24 on my system, too) locks the system up just as well. Thanks bye, Marc -- Marc UBM Bocklet ubm.free...@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
