Re: usb to serial
In message [EMAIL PROTECTED], Hans Petter Selasky writes: On Friday 10 November 2006 10:08, Maxim Konovalov wrote: The second question: is it OK to commit uark(4) as is and then convert it to the new model? I would prefer no. It is better to commit uark(4) to the USB p4 project, than HEAD, because then we don't have to worry about integrating the driver. If the driver works, then there should be no need to hold off on committing it to -CURRENT. Having it in -CURRENT now allows it to be MFC'd to RELENG_6 sooner. From a quick glance it looks fine to me, so I'd say just go ahead and commit it Maxim. Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
In message [EMAIL PROTECTED], Vivek Khera writes : On Feb 27, 2006, at 12:29 PM, Ed Maste wrote: I'm not having any luck getting my 115200 baud serial console back. The machine was upgraded from 5.4-STABLE to 6.1-PRE last week, and again over the weekend. I did the following: make buildworld and buildkernel with BOOT_COMCONSOLE_SPEED=115200 in / etc/make.conf, options CONSPEED=115200 in the kernel config. make installkernel, reboot, yada yada yada, installworld,.. then boot0cfg -B aacd0 to update the boot blocks. Now, at this point I expected to have a 115200 console on the next boot. Nope. Got 9600 baud again. There are a lot of steps to the boot process so it can be confusing - the command you wanted was disklabel, not boot0cfg. The boot0cfg program installs boot0, which is a 512-byte boot manager that you can optionally install in the MBR to give a menu of slices to boot from - it has nothing to do with reading /boot.config and doesn't set up the serial port. If the slice you boot from is aacd0s2 then you can use `disklabel -B aacd0s2' to install the new boot blocks (boot1 and boot2) into that slice. The other side-effect is now I get this stupid Boot F1 for DOS and F2 for FreeBSD menu which defaults to DOS (which is the Dell utility partition). How do I get back to the original boot style where it just boots freebsd without any menu? That's boot0. `fdisk -B /dev/aacd0' should put back the basic MBR. So I updated my /boot.config to read: -Dh -S115200 now on boot, the boot0 drops to the prompt and makes me type in / boot/loader to continue the process. It is as if it forgot what file to load, and ignores the -S option anyhow, because I still end up with a 9600 baud console. Presumably the boot loader (boot1/2) drops you at the prompt because it is old and does not understand the -S115200. Once you update the boot blocks with disklabel, that /boot.config should work. Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
In message [EMAIL PROTECTED], Mike Tancsa writes: I think I am almost there, but in my case, I get some strange char duplication after seeing the F1 prompt. The BIOS has console redirection, so I can see it throughout the bootup process. ... //bbtt..ccoo- ffiigg:: --DDhh// BTX loader 1.00 BTX version is 1.01 Consoles:ointernal video/keyboardalserialiportoo//kkeeyybbooaarrdd That's probably expected if you enable dual console mode (-D) when the BIOS is also redirecting VGA output to the serial port. Each character goes to both the serial port and the screen, but the BIOS is also copying screen characters to the serial port so each character appears twice. Once the kernel starts it no longer uses BIOS calls to output to the screen. There might be a BIOS option to disable the redirection when booting. Alternatively you could remove the -D, but you will no longer get kernel boot messages on the VGA console. Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
In message [EMAIL PROTECTED], Dimitry Andric writes: Ed Maste wrote: The way this is supposed to work is that you can put -Sspeed in /boot.config, which gets used by boot2, and the loader then detects that the serial console is already in use and defaults to the existing speed. Ah, I didn't try that yet. However, I would expect that the BOOT_COMCONSOLE_SPEED override in /etc/make.conf would simply continue to work as it had. comconsole_speed=115200 in loader.conf should override it if you don't want to replace boot2 or change /boot.config. Yes, I've tried this, but it didn't work, or maybe I just didn't try hard enough. :) I'll try it again with the 1.10.10.1 rev of comconsole.c. The problem may be that your boot blocks were compiled with BOOT_COMCONSOLE_SPEED set to 9600. Try reinstalling them with e.g. `disklabel -B ad0s1' (make sure you get the right device name - it should be the slice that you boot from). Previously both /boot/loader and the boot blocks would override the serial port speed according to BOOT_COMCONSOLE_SPEED, but I believe that since the recent change, loader will assume that if the boot blocks requested a serial console, then they will have already set up the correct speed. Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb/scanimage broken on 6.1-PRERELEASE
In message [EMAIL PROTECTED], Holger Kipp writes:
Problem still exists with the latest 6.1-PRERELEASE - build
just finished (FreeBSD 6.1-PRERELEASE #11: Sun Feb 26 00:56:42 CET 2006).
scanimage will remain in state uscnrb.
Help and suggestions welcome!
One change that went in since Feb 13th was removing code that clears
USB endpoint stalls every time a pipe is opened. It's possible that
this is causing problems with the USB data toggle value not being
set correctly, since a side-effect of clearing stalls is to reset
the device's idea of the correct toggle value.
You could try the following patch on the off-chance that it helps -
unfortunately I haven't found any devices that exibit this problem
yet, so I can't tell if this patch actually does what it should.
Ian
Index: ehci.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ehci.c,v
retrieving revision 1.36.2.1
diff -u -r1.36.2.1 ehci.c
--- ehci.c 26 Jan 2006 01:43:13 - 1.36.2.1
+++ ehci.c 25 Feb 2006 23:54:55 -
@@ -1390,7 +1390,7 @@
if (sc-sc_dying)
return (USBD_IOERROR);
- epipe-nexttoggle = 0;
+ epipe-nexttoggle = pipe-endpoint-savedtoggle;
if (addr == sc-sc_addr) {
switch (ed-bEndpointAddress) {
@@ -2479,6 +2479,8 @@
ehci_rem_qh(sc, sqh, head);
splx(s);
ehci_free_sqh(sc, epipe-sqh);
+
+ pipe-endpoint-savedtoggle = epipe-nexttoggle;
}
/*
Index: ohci.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ohci.c,v
retrieving revision 1.154.2.2
diff -u -r1.154.2.2 ohci.c
--- ohci.c 29 Jan 2006 01:26:46 - 1.154.2.2
+++ ohci.c 25 Feb 2006 23:55:31 -
@@ -2161,7 +2161,9 @@
(dev-speed == USB_SPEED_LOW ? OHCI_ED_SPEED : 0) |
fmt |
OHCI_ED_SET_MAXP(UGETW(ed-wMaxPacketSize)));
- sed-ed.ed_headp = sed-ed.ed_tailp = htole32(tdphys);
+ sed-ed.ed_headp = htole32(tdphys |
+ (pipe-endpoint-savedtoggle ? OHCI_TOGGLECARRY : 0));
+ sed-ed.ed_tailp = htole32(tdphys);
switch (xfertype) {
case UE_CONTROL:
@@ -2247,6 +2249,8 @@
/* Make sure the host controller is not touching this ED */
usb_delay_ms(sc-sc_bus, 1);
splx(s);
+ pipe-endpoint-savedtoggle =
+ (le32toh(sed-ed.ed_headp) OHCI_TOGGLECARRY) ? 1 : 0;
ohci_free_sed(sc, opipe-sed);
}
Index: uhci.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/uhci.c,v
retrieving revision 1.162
diff -u -r1.162 uhci.c
--- uhci.c 29 May 2005 04:42:27 - 1.162
+++ uhci.c 25 Feb 2006 23:58:05 -
@@ -2031,6 +2031,7 @@
uhci_softc_t *sc = (uhci_softc_t *)dev-bus;
uhci_free_sqh(sc, upipe-u.bulk.sqh);
+ pipe-endpoint-savedtoggle = upipe-nexttoggle;
}
usbd_status
@@ -2915,7 +2916,7 @@
ed-bEndpointAddress, sc-sc_addr));
upipe-aborting = 0;
- upipe-nexttoggle = 0;
+ upipe-nexttoggle = pipe-endpoint-savedtoggle;
if (pipe-device-address == sc-sc_addr) {
switch (ed-bEndpointAddress) {
Index: usb_subr.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.76.2.2
diff -u -r1.76.2.2 usb_subr.c
--- usb_subr.c 15 Feb 2006 22:51:08 - 1.76.2.2
+++ usb_subr.c 25 Feb 2006 23:58:36 -
@@ -514,6 +514,7 @@
}
}
ifc-endpoints[endpt].refcnt = 0;
+ ifc-endpoints[endpt].savedtoggle = 0;
p += ed-bLength;
}
#undef ed
Index: usbdivar.h
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/usbdivar.h,v
retrieving revision 1.43
diff -u -r1.43 usbdivar.h
--- usbdivar.h 6 Jan 2005 01:43:29 - 1.43
+++ usbdivar.h 25 Feb 2006 23:58:40 -
@@ -51,6 +51,7 @@
struct usbd_endpoint {
usb_endpoint_descriptor_t *edesc;
int refcnt;
+ int savedtoggle;
};
struct usbd_bus_methods {
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_6: serial console drops back from 115200 to 9600 baud
In message [EMAIL PROTECTED], Dimitry Andric writes:
Okay, but why did 4.x through 5.x through 6.x (these have all been on
this particular machine) always boot with 115200 until now? :)
They probably used 9600 for the boot blocks, and then switched to
115200 when /boot/loader started, so you didn't notice. Now the
settings from the boot blocks get used by /boot/loader.
Anyway, I also thought that installworld would take care of installing
any updated boot blocks, if necessary. I'll manually install them and
see what I end up with.
Boot blocks need to be installed manually - installworld installs
the boot blocks as files in /boot/boot{1,2}, but when booting, it
is the boot blocks in the first 8k of the slice that are used, not
the /boot/boot{1,2} files.
Ah, but notice that I didn't use boot0sio, but the regular boot0. It
seems the serial port speed setting is compiled out in the latter
version. Hence the port speed will be the BIOS default, which I alas
can't change; it's always 9600n1.
The boot blocks in question here are the ones installed inside the
slice (boot1 and boot2), rather than the boot0 MBR boot code, which
is installed in the very first sector of the disk. The boot0 boot
manager selects which slice to boot from, and then it invokes the
boot{1,2} blocks within the slice, they load /boot/loader and it
loads the kernel.
Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0-stable panic in ohci_softintr when using ucom/uftdi
In message [EMAIL PROTECTED], Paul Koch writes: As soon at the modem rings, the machine panics. I don't think the modem even gets time to pick up the line. This doesn't happen on a 5.4-stable box with 6 modems connected, but 5.4-stable appears to have other hanging issues, thus why I am trying out 6.0-stable. Recent changes to ohci.c (1.154.2.1) in this area (2 days ago) ?? Should I raise a PR ? I'll see if I can reproduce this later - the only thing I can think of now that might be responsible is a USB transfer reuse issue that the old patch here might help with: http://people.freebsd.org/~iedowse/releng_5_xfer_reuse.diff Could you see if that makes any difference? It should apply to 6-stable even though the name says releng_5. Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Too short ethernet frame...
In message [EMAIL PROTECTED], Iva Hesy writes:
OK, now, I get the result:
tag=RELENG_6 date=2005.07.30.22.00.00 works fine, tag=RELENG_6
date=2005.07.31.03.00.00 makes noise, many many ethernet frames can
be sniffered.
the cvsup log:
Updating collection src-all/cvs
Edit src/sys/dev/mlx/mlx_pci.c
Add delta 1.23.2.1 2005.07.31.00.41.53 csjp
Edit src/sys/net/bpf.c
Add delta 1.153.2.1 2005.07.31.00.48.18 csjp
Edit src/sys/net/bpfdesc.h
Add delta 1.29.2.1 2005.07.31.00.48.18 csjp
Shutting down connection to server
Finished successfully
I guess it should be bpf.c...
There appear to be some braces missed in that revision of bpf.c. Does
the following patch help?
Ian
Index: sys/net/bpf.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/net/bpf.c,v
retrieving revision 1.153.2.2
diff -u -r1.153.2.2 bpf.c
--- sys/net/bpf.c 13 Aug 2005 21:24:16 - 1.153.2.2
+++ sys/net/bpf.c 18 Aug 2005 08:55:49 -
@@ -1256,13 +1256,14 @@
BPFD_LOCK(d);
++d-bd_rcount;
slen = bpf_filter(d-bd_filter, (u_char *)m, pktlen, 0);
- if (slen != 0)
+ if (slen != 0) {
d-bd_fcount++;
#ifdef MAC
if (mac_check_bpfdesc_receive(d, bp-bif_ifp) == 0)
#endif
catchpacket(d, (u_char *)m, pktlen, slen,
bpf_mcopy);
+ }
BPFD_UNLOCK(d);
}
BPFIF_UNLOCK(bp);
@@ -1308,13 +1309,14 @@
BPFD_LOCK(d);
++d-bd_rcount;
slen = bpf_filter(d-bd_filter, (u_char *)mb, pktlen, 0);
- if (slen != 0)
+ if (slen != 0) {
d-bd_fcount++;
#ifdef MAC
if (mac_check_bpfdesc_receive(d, bp-bif_ifp) == 0)
#endif
catchpacket(d, (u_char *)mb, pktlen, slen,
bpf_mcopy);
+ }
BPFD_UNLOCK(d);
}
BPFIF_UNLOCK(bp);
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EHCI: mtools stuck in state 'physrd' or panic
In message [EMAIL PROTECTED], Stefan Walter write
s:
FYI: I have just sent a PR for this problem.
http://www.freebsd.org/cgi/query-pr.cgi?pr=82660
OpenBSD have a workaround for problems with VIA EHCI controllers
that can cause the hanging symptoms you describe. Below is a patch
that implements their change in FreeBSD's driver. Could you try it
to see if it helps?
Thanks,
Ian
Index: sys/dev/usb/ehci.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ehci.c,v
retrieving revision 1.14.2.9
diff -u -r1.14.2.9 ehci.c
--- sys/dev/usb/ehci.c 31 Mar 2005 19:47:11 - 1.14.2.9
+++ sys/dev/usb/ehci.c 26 Jun 2005 16:21:11 -
@@ -155,6 +155,7 @@
Static voidehci_idone(struct ehci_xfer *);
Static voidehci_timeout(void *);
Static voidehci_timeout_task(void *);
+Static voidehci_intrlist_timeout(void *);
Static usbd_status ehci_allocm(struct usbd_bus *, usb_dma_t *, u_int32_t);
Static voidehci_freem(struct usbd_bus *, usb_dma_t *);
@@ -491,6 +492,7 @@
EOWRITE4(sc, EHCI_ASYNCLISTADDR, sqh-physaddr | EHCI_LINK_QH);
usb_callout_init(sc-sc_tmo_pcd);
+ usb_callout_init(sc-sc_tmo_intrlist);
lockinit(sc-sc_doorbell_lock, PZERO, ehcidb, 0, 0);
@@ -694,6 +696,11 @@
ehci_check_intr(sc, ex);
}
+ /* Schedule a callout to catch any dropped transactions. */
+ if ((sc-sc_flags EHCI_SCFLG_LOSTINTRBUG)
+ !LIST_EMPTY(sc-sc_intrhead))
+ usb_callout(sc-sc_tmo_intrlist, hz, ehci_intrlist_timeout, sc);
+
#ifdef USB_USE_SOFTINTR
if (sc-sc_softwake) {
sc-sc_softwake = 0;
@@ -942,6 +949,7 @@
EOWRITE4(sc, EHCI_USBINTR, sc-sc_eintrs);
EOWRITE4(sc, EHCI_USBCMD, 0);
EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET);
+ usb_uncallout(sc-sc_tmo_intrlist, ehci_intrlist_timeout, sc);
usb_uncallout(sc-sc_tmo_pcd, ehci_pcd_enable, sc);
#if defined(__NetBSD__) || defined(__OpenBSD__)
@@ -2701,6 +2708,30 @@
splx(s);
}
+
+/*
+ * Some EHCI chips from VIA seem to trigger interrupts before writing back the
+ * qTD status, or miss signalling occasionally under heavy load. If the host
+ * machine is too fast, we we can miss transaction completion - when we scan
+ * the active list the transaction still seems to be active. This generally
+ * exhibits itself as a umass stall that never recovers.
+ *
+ * We work around this behaviour by setting up this callback after any softintr
+ * that completes with transactions still pending, giving us another chance to
+ * check for completion after the writeback has taken place.
+ */
+void
+ehci_intrlist_timeout(void *arg)
+{
+ ehci_softc_t *sc = arg;
+ int s = splusb();
+
+ DPRINTFN(3, (ehci_intrlist_timeout\n));
+ usb_schedsoftintr(sc-sc_bus);
+
+ splx(s);
+}
+
//
Static usbd_status
Index: sys/dev/usb/ehci_pci.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ehci_pci.c,v
retrieving revision 1.14.2.2
diff -u -r1.14.2.2 ehci_pci.c
--- sys/dev/usb/ehci_pci.c 13 Jun 2005 09:00:19 - 1.14.2.2
+++ sys/dev/usb/ehci_pci.c 26 Jun 2005 16:21:11 -
@@ -303,6 +303,10 @@
return ENXIO;
}
+ /* Enable workaround for dropped interrupts as required */
+ if (pci_get_vendor(self) == PCI_EHCI_VENDORID_VIA)
+ sc-sc_flags |= EHCI_SCFLG_LOSTINTRBUG;
+
/*
* Find companion controllers. According to the spec they always
* have lower function numbers so they should be enumerated already.
Index: sys/dev/usb/ehcivar.h
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ehcivar.h,v
retrieving revision 1.4.2.4
diff -u -r1.4.2.4 ehcivar.h
--- sys/dev/usb/ehcivar.h 22 Mar 2005 00:56:54 - 1.4.2.4
+++ sys/dev/usb/ehcivar.h 26 Jun 2005 16:21:11 -
@@ -93,6 +93,7 @@
#define EHCI_COMPANION_MAX 8
#define EHCI_SCFLG_DONEINIT0x0001 /* ehci_init() has been called. */
+#define EHCI_SCFLG_LOSTINTRBUG 0x0002 /* workaround for VIA chipsets */
typedef struct ehci_softc {
struct usbd_bus sc_bus; /* base device */
@@ -149,6 +150,7 @@
struct lock sc_doorbell_lock;
usb_callout_t sc_tmo_pcd;
+ usb_callout_t sc_tmo_intrlist;
device_ptr_t sc_child; /* /dev/usb# device */
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Boot loader cant identify ntfs?
In message [EMAIL PROTECTED], Doug White writes: On Wed, 18 May 2005, Matthias Buelow wrote: Obviously the Right Way of doing such things is to move this into the 2nd stage boot loader... I can't think of any reason (except quick hackery) why this hasn't been done that way. I mean, one could retain a simple choice of which disk/partition to boot in the 1st stage (to cover all eventualities), and maybe hide it by having to hit a key, and do the real menu in the 2nd stage, perhaps integrated with the kernel options boot menu. Then the space problem just migrates. There's a limited amount of space in the disklabel for bootblocks and I think we're pushing that. BTW, one potential improvement to the current boot0 situation would be to have boot0cfg dynamically generate the OS table based on what partition types actually exist on the disk. That would allow a bit more flexibility without increasing the space requirement. Anyone care to attempt a patch for this? Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MNT_USER?
In message [EMAIL PROTECTED], Danny Braniss writes: after doing a mount_nfs as root (from the console or via su), statfs reports that MNT_USER flags is set! this is also true with 5.4. It's a bug in the statfs reporting for NFS filesystems. It should be fixed now in -CURRENT (revision 1.174 of sys/nfsclient/nfs_vfsops.c). I'll merge this to -STABLE in a week or so. Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic after plugging in an mp3 usb player, 5.4-PRERELEASE
In message [EMAIL PROTECTED], Radek Kozlowski writes: My 5.4-PRERELEASE/i386 as of today panics almost immediately after plugging in an mp3 usb player (Qware BeatZkey! Pro 512MB). I don't have device ehci in the kernel. Hi, Did this just suddenly stop working when you updated to the latest 5.x-stable, or did it ever work for you before? There were a number of USB changes in 5.4-PRERELEASE yesterday, so it's important to know whether they broke anything. If the problem is not new then it may just require a quirk as already suggested. Thanks, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-PRERELEASE panics on boot with ipod shuffle plugged in
In message [EMAIL PROTECTED], Matthias Buelow writes: Hi folks, when I have an iPod Shuffle(tm) inserted at boot in an USB slot, the kernel panics before it reaches the point where it starts init. This is on a Dell Dimension 4700 machine running FreeBSD 5.4-PRERELEASE i386. I get a fatal trap 12 panic. Anybody else seeing this? Is it a known problem with the USB subsystem? I can build a debug kernel and try to produce a crash dump but that can take a while. Hi, If possible, could you try updating to the latest 5.x-STABLE? I've just finished merging all of the recent changes from -CURRENT, so there is a good chance that things might work better now. By the way, did you have `device ehci' compiled into your kernel? The support for EHCI controllers is what should be most improved by the recent updates. Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Mouse not working
In message [EMAIL PROTECTED], Marius =?ISO- 8859-1?Q?N=FCnnerich?= writes: # usbhidctl -f /dev/uhid0 -ra Report descriptor: Total input size 0 bytes Total output size 4 bytes Total feature size 1 bytes usbhidctl: device does not support immediate mode, only changes reported. Hmm, don't know what to do with this information :) I'm not sure I do either :-) On a mouse I tried here I got very different information than that: Report descriptor: Collection page=Generic_Desktop usage=Mouse Collection page=Generic_Desktop usage=Pointer Input size=1 count=1 page=Button usage=Button_1, logical range 0..1 Input size=1 count=1 page=Button usage=Button_2, logical range 0..1 Input size=1 count=1 page=Button usage=Button_3, logical range 0..1 Input size=8 count=1 page=Generic_Desktop usage=X, logical range -127..127 Input size=8 count=1 page=Generic_Desktop usage=Y, logical range -127..127 Input size=8 count=1 page=Generic_Desktop usage=Wheel, logical range -127..127 End collection Feature size=1 count=1 page=Generic_Desktop usage=Motion_Wakeup, logical range 0..1 End collection Total input size 4 bytes Total output size 0 bytes Total feature size 0 bytes But I don't know enough about how this is supposed to work to make sense of the difference. Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Mouse not working
In message [EMAIL PROTECTED], Anish Mistry writes: sc-flags |= UMS_T; /* --- Add this to force MS Intellimouse Mode */ If that make is work we'll have to figure out a way to auto detect this since it uses the same byte order, but doesn't have the tilt wheel to facilitate detection. BTW, before adding more workarounds here it would be worth reading: http://www.usb.org/developers/devclass_docs/HID1_11.pdf I don't know if this is true, but I suspect the main problem is that we are simply ignoring the information in the report descriptor that says how to interpret the data coming from the mouse. Can somebody check if this is the case, or if these mice really need special case workarounds? Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB Mouse not working
In message [EMAIL PROTECTED], Marius =?ISO- 8859-1?Q?N=FCnnerich?= writes: On Sun, 20 Mar 2005 19:29:18 + Ian Dowse [EMAIL PROTECTED] wrote: BTW, before adding more workarounds here it would be worth reading: http://www.usb.org/developers/devclass_docs/HID1_11.pdf I don't know if this is true, but I suspect the main problem is that we are simply ignoring the information in the report descriptor that says how to interpret the data coming from the mouse. Can somebody check if this is the case, or if these mice really need special case workarounds? I didn't read the whole document, but as far as I understand the table on the bottom of page 61 (of the document, not the pdf-file) it is clear how the data should be interpreted, and that my mouse (like the intellimouse) is not conforming to this standard. I think page 61 is just an example of one possible report descriptor for a mouse. Could you follow the instructions below to get the report descriptor for your mouse and post it to the list? o Remove the `ums' device from your kernel config, but leave in the `uhid' device (if you're using modules, just unload ums and make sure uhid is loaded). o Plug in the mouse o Check dmesg for the correct uhid device, e.g. you should see something like: uhid0: Logitech USB Mouse, rev 1.10/4.10, addr 2, iclass 3/1 o Run this command usbhidctl -f /dev/uhid0 -ra replacing the uhid0 name with the correct device for your mouse. Thanks, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0: failed to allocate descriptors: 12
In message [EMAIL PROTECTED], Sam Leffler writes: Memmory is too fragmented to allocate the descriptors in one chunk. I changed this logic in current to allocate separate blocks for the tx+rx+beacon descriptors; I'll look at backporting that (though it's too risky to get into 5.4). I've always got it to work with the patch below - I seem to remember calculating that 32k rather than 256k was all that was needed for the old descriptor arrangement, but you probably know the real reason for the larger allocation. Ian Index: if_ath_pci.c === RCS file: /dump/FreeBSD-CVS/src/sys/dev/ath/if_ath_pci.c,v retrieving revision 1.8.2.2 diff -u -r1.8.2.2 if_ath_pci.c --- if_ath_pci.c7 Feb 2005 18:01:28 - 1.8.2.2 +++ if_ath_pci.c19 Mar 2005 20:57:54 - @@ -197,7 +197,7 @@ BUS_SPACE_MAXADDR_32BIT, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ - 0x3, /* maxsize XXX */ + 0x7fff, /* maxsize XXX */ ATH_MAX_SCATTER, /* nsegments */ 0x, /* maxsegsize XXX */ BUS_DMA_ALLOCNOW,/* flags */ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4.10 kernel panic: Fatal trap 12: page fault while in kernel mode
In message [EMAIL PROTECTED], Peter Jeremy wri tes: On Wed, Dec 15, 2004 at 12:42:25PM -0800, Scott Sewall wrote: I'm running FreeBSD 4.10-RELEASE-p3 that occasionally panics. The panic occurs seems to happen when I'm running rsync of large directories possibly in combination with reading or writing to a compact flash attached to USB. Having just looked into an identical panic, the problem is an interface bug between bus_dmamem_alloc() and contigmalloc(). It's nothing to do with USB and (AFAIK) exists in 4.x, 5.x and 6.x. The USB code is not entirely free of blame here however. It allocates numerous big chunks of contiguous memory for tranfer buffers instead of using the (admittedly limited) scatter-gather capabilities of the USB host controllers. Try applying the change from revision 1.6 of usb_mem.c. This fixed one particularly inefficient memory use behaviour in the USB code. That change is already in 5.x and 6.x, but wasn't merged to 4.x. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usb_mem.c Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in bootpd for FBSD-stable ?
In message [EMAIL PROTECTED], Mat thew Seaman writes: On Sat, Feb 07, 2004 at 07:52:12AM +0900, Rob wrote: ... --- .default:\ hn:ht=1:vm=rfc1048:\ sm=255.255.255.0:\ sa=147.46.44.181:\ gw=147.46.44.1:\ hd=:\ bf=kernel:\ T128=147.46.44.181:/home:\ T129=64000:\ rp=147.46.44.181:/tftpboot: tc=.default: ... But then I get in /var/log/messages this line: Feb 6 20:06:45 cisr bootpd[842]: in entry named .default, symbol T128: bad syntax Feb 6 20:06:45 cisr bootpd[842]: can't find tc=.default Rob, are you sure that the error was on the T128 line? The above bootptab appears to have just one syntax error, but it is on the T129 line. From bootptab(5): There is also a generic tag, Tn, where n is an RFC1084 vendor field tag number. Thus it is possible to immediately take advantage of future extensions to RFC1084 without being forced to modify bootpd first. Generic data may be represented as either a stream of hexadecimal numbers or as a quoted string of ASCII characters. The length of the generic data is automatically determined and inserted into the proper field(s) of the RFC1084-style bootp reply. The error is that `64000' is neither a quoted string nor a stream of hexadecimal bytes. Try this instead: T129=fa00:\ There seems to be incorrect advice about this in the handbook, as FreeBSD's bootpd and kernel has always required the swap size to be specified this way. Note also that this mechanism of setting up swap no longer works in FreeBSD 5.x. Read the man page more closely, and consult termcap(5) for the general syntax. One obscure requirement is: Bootpd does not use termcap(5) syntax, so none of this is relevant. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Strange installworld failure.
In message [EMAIL PROTECTED], stable @d.sparks.net writes: w3c-libwww/WWWZip.h - w3c-libwww/WWWZip.ph w3c-libwww/wwwsys.h - w3c-libwww/wwwsys.ph w3c-libwww/xmlparse.h - w3c-libwww/xmlparse.ph *** Error code 1 When I've seen this before it has been caused by a dangling symlink in /usr/include. Look back carefully through all of the xxx.h - xxx.ph lines and you should find an error there somewhere that gives the name of the problem file. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Patch for boot-time USB hangs in 4.9-PRERELEASE
Could people who are experiencing boot-time hangs in 4.9-PRERELEASE try the following patch to see if it helps? I've had one positive report so far, but it would be helpful to get more feedback to determine if this is the right fix to be committed. The problem was that interrupts were getting unmasked too early in the boot process, causing an interrupt storm that usually occurred while USB devices were being probed. The bug is in fork1(), which is used by kthread_create() to create kernel threads; the code there assumed that all interrupts would be unmasked when called, so it didn't bother saving and restoring the interrupt mask. This assumption is reasonable for normal fork() calls, but not for the creation of kernel threads early in the boot process. The appearance of the problem was linked to some recent changes in sys/kern/subr_taskqueue.c around September 10th. Those changes include a call to kthread_create() that happens just before probing all the devices at boot time, so the result was that interrupts were being left unmasked at a time when they are supposed to be disabled. To actually get an interrupt storm hang, you need some IRQ number to be configured by a device driver, and then for some (possibly other) device sharing that IRQ line to generate an interrupt before the driver for that device is prepared to handle it. As well as the subr_taskqueue.c case, there is also a call to kthread_create() in the USB code, so that might be related too. Apply the patch in /usr/src/sys/kern, then rebuild the kernel and reboot. In case of whitespace problems preventing patch applying, it is also available at: http://people.freebsd.org/~iedowse/fork.diff Ian Index: kern_fork.c === RCS file: /home/iedowse/CVS/src/sys/kern/kern_fork.c,v retrieving revision 1.72.2.14 diff -u -r1.72.2.14 kern_fork.c --- kern_fork.c 26 Jun 2003 04:15:10 - 1.72.2.14 +++ kern_fork.c 26 Sep 2003 08:26:31 - @@ -183,7 +183,7 @@ struct proc *p2, *pptr; uid_t uid; struct proc *newproc; - int ok; + int ok, s; static int curfail = 0, pidchecked = 0; static struct timeval lastfail; struct forklist *ep; @@ -544,10 +544,10 @@ */ microtime((p2-p_stats-p_start)); p2-p_acflag = AFORK; - (void) splhigh(); + s = splhigh(); p2-p_stat = SRUN; setrunqueue(p2); - (void) spl0(); + splx(s); /* * Now can be swapped. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4,7 Kernel panic
In message [EMAIL PROTECTED], Roger Savard writes: Even with the latest : nexus_print_all_ressources(... That is the other 4.7 problem that people have been reporting recently, but only on some hardware. You could try reverting John Baldwin's latest change to src/sys/i386/i386/nexus.c by grabbing version 1.26.2.6 of that file from http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/i386/i386/nexus.c?rev=1.26.2.6 Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: src/sbin/ping.c
In message [EMAIL PROTECTED], Yutaka KAWASE writes: I just noticed -A option is not indicated in usage(). Fixed, thanks! Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: boot0cfg and fdisk will not write an mbr to boot past cyl. 1023
In message [EMAIL PROTECTED], Kevin Oberman writes: I have confirmed that fdisk under sysinstall(8) writes a boot block that will work for booting from slices that begin past cylinder 1023. boot0cfg(8) and fdisk(8) write an MBR that is unable to boot from a slice that starts above 1023. Did you try boot0cfg -o packet? From boot0cfg(8): packet Use the disk packet (BIOS Int 0x13 extensions) interface, as as opposed to the legacy (CHS) interface, when doing disk I/O. This allows booting above cylinder 1023, but requires specific BIOS support. The default is `nopacket'. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: panics after upgrading to -STABLE Aug 9, 2002
In message [EMAIL PROTECTED], Scott Lambert writes: I've been getting regular panics today after CVSuping and following the UPDATING procedure. I think all of the panics are happening as various network apps are tearing down their connections. I've had it trap while in the kernel on the behalf of fetchmail, ppp, and nfsd (when I kill -9'd nfsd to try to make sure I wouldn't panic during a buildkernel, and during a shutdown.). See the patch at the end of: http://www.freebsd.org/cgi/query-pr.cgi?pr=41492 If this is the same problem, then I think reverting revision 1.51.2.17 of uipc_mbuf.c should also fix it. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cdrom can't be mounted under freeBSD 4.5-stable
Interesting, because in the /dev/MAKEDEV script is this concerning the minor number: ... ... which is exactly what I have. What's in your MAKEDEV? When/why did the + 2 get in there if it's incorrect? You have a stale MAKEDEV. You need at least revision 1.243.2.45 (March 18th) to pick up the changes that occurred with the big ATA merge from -current. Maybe you forgot to run mergemaster after updating? Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: NFS Server Ret-failed ?
In message 056601c1ead0$4fcc70e0$[EMAIL PROTECTED], Robert Blayzor writes: value jumps at the rate of about 20 per second. I don't remember pre 4.5-stable boxes doing this, but I could be wrong. Like I said, the server seems to be running fine and performance is great... Any ideas or comments? Server Ret-Failed 174405 This is just telling you the number of operations that returned a failure code to the client. It includes all of the normal errors you get when accessing files (file not found, file exists, no space left on device, is a directory etc. etc.), so there is nothing unusual about seeing this number grow quite quickly. To see the actual errors, run tcpdump with a suitably large snaplen and look at the lines containing ERROR and the preceding requests. You'll probably mainly see stuff like programs looking for optional config files or trying each component of $PATH. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: on/off NFS connection errors
In message [EMAIL PROTECTED], Marius M. Rex writes: 118Dec 15 22:40:19 cc117 /kernel: nfs server netapp1:/vol/members: not responding 118Dec 15 22:40:19 cc117 /kernel: nfs server netapp1:/vol/members: is alive again ... Has anyone else seen these kinds of persistent NFS errors is the 4.x branch? These are a side-effect of the operation of the NFS dynamic retransmit timeout code. The NFS client measures the request response time for various types of operations and it sets a timeout based on the mean and deviation of observed times. The time taken by the server to perform some operations can vary wildly though, so occasionally when a large number of operations complete with very little delay, the response time estimate and hence the timeout become very small. Then when one request is unusually slow to complete (such as when the disk on the server is busy), the client thinks that the server isn't responding and prints those warnings. A fraction of a second later the request completes and the client prints a an 'is alive again' message. On non-soft mounts these messages are completely harmless because the client will just wait for the server to eventually reply. On soft mounts, the effect can cause problems because applications occasionally see an EINTR error. The dynamic retransmit timeout code can be disabled with the `-d' flag to mount_nfs; this is often recommended for fast networks that see very little packet loss. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 4.4-STABLE install fails
In message [EMAIL PROTECTED], David writes: As the subject say's, i've tried 2 different clean cvsup's from 2 different servers, clean as in, cleaned out obj, and /usr/src. Both times the buildworld and buildkernel complete without any errors, but when doing installworld, both install's fail at the same point. You missed the real error messages, which are: ansidecl.h - ansidecl.ph Can't open ansidecl.h: No such file or directory bfd.h - bfd.ph Can't open bfd.h: No such file or directory So you probably have dangling symlinks called ansidecl.h and bfd.h in /usr/include. Removing them should fix the problem. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Have root on vinum, one small problem..
In message 4FC7AFEB1135D4119926F87A88260D9530@TRSBS, Chris Williams write s: Things seems to be working quite well, but there is one strange behavior which worries me; whenever I shut down, right after syncing I get a panic: panic: Vrele: negative ref cnt I noticed this a while ago - it is due to inconsistent handling of 'rootvnode' in the kernel. You should find the details if you search for 'rootvnode' in the -hackers archive. The following patch should work around the panic by adding an extra vnode reference for rootvp: Ian Index: init_main.c === RCS file: /FreeBSD/FreeBSD-CVS/src/sys/kern/init_main.c,v retrieving revision 1.134.2.3 diff -u -r1.134.2.3 init_main.c --- init_main.c 2000/09/07 19:13:36 1.134.2.3 +++ init_main.c 2001/02/02 16:01:52 @@ -456,6 +456,7 @@ VREF(fdp-fd_fd.fd_cdir); VOP_UNLOCK(rootvnode, 0, proc0); fdp-fd_fd.fd_rdir = rootvnode; + VREF(fdp-fd_fd.fd_rdir); } SYSINIT(retrofit, SI_SUB_ROOT_FDTAB, SI_ORDER_FIRST, xxx_vfs_root_fdtab, NULL) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
