UHCI/USB related panic while
I just upgraded a machine to this morning's version of the RELENG_4
branch of FreeBSD. I had problems booting it, where it would hang for
a bit, and then panic while probing for USB peripherals.
There was a USB hub plugged into the UHCI 2-port built-in "hub", and a USB
mouse plugged into the external hub. Attempting to boot with just the
external hub or just the external USB mouse seemed to break the same
way. As this machine has a somewhat critical role, I couldn't spend
a lot of time experimenting. I did jot down some of the information,
and it seems like uhci_idone() is invoked with a null pointer; the
fault virtual address is 0x4, which happens to be the offset of
ii->xfer in the structure..
What's interesting is that after the system is booted, I can plug
in the USB mouse, and things work just fine.
Does this ring a bell for anyone?
(kgdb) x/i 0xc02afecc
0xc02afecc : mov0x4(%eax),%ebx
(kgdb) list *0xc02afecc
0xc02afecc is in uhci_idone (/usr/src/sys/dev/usb/uhci.c:1065).
1060
1061/* Called at splusb() */
1062void
1063uhci_idone(uhci_intr_info_t *ii)
1064{
1065usbd_xfer_handle xfer = ii->xfer;
1066struct uhci_pipe *upipe = (struct uhci_pipe *)xfer->pipe;
1067uhci_soft_td_t *std;
1068u_int32_t status = 0, nstatus;
1069int actlen;
(kgdb)
When the system boots, I see this much on the console:
uhci0: port 0xdce0-0xdcff irq 2 at device
7.2 on pci0
usb0: on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
and then there's this ominious hang followed by the panic.
louie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: 4.6-RELEASE delayed
Just some feedback, perhaps for release notes regarding the new dhclient DHCP client program. I've been using FreeBSD 4-STABLE in an embedded system environment (Soekris net4501) where the system boots and runs a stripped down FreeBSD installation from a Compact Flash card. I had a dhclient-related problem when upgrading to a version with the new dhclient. If the dhclient-script exits abnormally, then the dhclient program again attempts to acquire an address from the DHCP server. In my environment, the root file system is mounted read-only, and the dhclient-script shell script fails when it attempts to update /etc/resolv.conf with the name servers and default domain returned from the DHCP server. The system would pause indefinately during boot repeatedly trying to get an IP address, and then failing to update the read-only /etc/resolv.conf file. It also leaves a route for each address it acquired on the loopback interface which is not removed when the next attempt is made. You can't configure the "update /etc/resolv.conf" behavior, so I had to manually edit the /sbin/dhclient-script to resolve this issue. The older version of /sbin/dhclient ignored the error when trying to update /etc/resolv.conf. Louis Mamakos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Weird path MTU autodiscovery problem in 4.5-RELEASE
Is the server filtering out ICMP traffic with ipfw or something? > Alexey Luckyanchikov wrote: > > > > 14:06:48.477578 server.7 > client.1371: . 1437:2897(1460) ack 10001 win 65535 (DF) >(ttl 64, id 25428, len 1500) > > ^^^ > > Server send packet with size 1500 bytes > > > > 14:06:48.682558 router > server: icmp: client unreachable - need to frag (mtu >1476) for server.7 > client.1371: [|tcp] (DF) (ttl 61, id 25428, len 1500) (ttl 253, >id 2491, len 56) > > ^^ > > Router say to server that he must to decrease packet size > > > > 14:07:04.477857 server.7 > client.1371: . 1437:2897(1460) ack 10001 win 65535 (DF) >(ttl 64, id 52781, len 1500) > > ^ > > But server ignore this information and still send 1500 bytes packets > > > What's the result of 'sysctl net.inet.tcp.path_mtu_discovery' ?? Not that > I can imagine, at the moment, what would set it to 0 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: odd mouse button behavior
> > Latest discovery: the mouse will work fine if you choose "/dev/pms0" > and "auto" as mouse device and protocol type. But you have to kill > "moused". > > Looks like XFree-4 does not like moused for some reason... It sounds then like some weird moused interaction. Not using moused is probably not an option for me, as I'm using a USB mouse. But it does give me a place to start looking. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: odd mouse button behavior
> > > Unless I got your description wrong and you do release the button > > and X doesn't notice. Then I couldn't help you. But it might be > > helpful to have the above emulation "discussion" and its side > > effect of delay in the archive "for the record". :) > > > > It does this: > > Press mouse button > Release mouse button > > See button widget go down (that is, mouse-down event) > > (nothing happens if I keep the mouse still: there is no timeout!) > > Move mouse > > See widget go up and activate UI action... it happens in WING, gtk and > qt. > > > > I told XFree that > > Option "Emulate3Buttons" "off" > Option "Emulate3Timeout" "0" > Option "Buttons" "3" > > but it has the same behavior without these options. > > So I'm puzzled. Any hints anyone? Same here, I don't have 3 button emulation enabled. I'm using XFree 4 and no mention of 3 button emulation in the X server config file. My moused also does not attempt to do 3rd button emulation, either. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HDD Problem
I've got two mobos with VIA MVP3 chipsets on-board. As these systems (until recently) had only SCSI peripherals, I didn't notice any problem. However, when I added an IDE CDRW drive, I got these very strange system lock-ups/hangs. Specifically, this was an FIC VA-503+ mobo, with a 450MHz K6-2 CPU. I saw on a FreeBSD mailing list a suggestion to go into the BIOS setup, and disable "PCI Dynamic Bursting". At least that's what it's called in my Award BIOS. This seemed to have "fixed" the problem for me (or at least hidden it sufficiently well :-); perhaps it might be of some help in other situations? louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Ethernet MTUs > 1500?
> > "Joerg" == Joerg Micheel <[EMAIL PROTECTED]> writes: > > Joerg> On Mon, Jul 03, 2000 at 11:23:13PM -0400, David Gilbert wrote: > >> But a number of devices seem to allow for MTUs > 1500 on 100Mb > >> ethernet... and several people have told me that the standard > >> allows for packets bigger than 1500 bytes. > > Joerg> The limit is 1536. That is hex 0x600, a value of importance if > Joerg> using 802.x networks. A value below 0x600 indicates the length > Joerg> of an additional header in the EtherType field. If this value > Joerg> is above 0x600 it indicates a certain protocol (such as 0x800 > Joerg> for IP, 0x806 for IP ARP). > > Joerg> I would not twiddle with the settings, the extra gain is very > Joerg> low and you'll face all sorts of compatibility issues with > Joerg> devices not supporting it. > > Well... all I'm looking for is the ability to set 1504 on the etnernet > device so that 1500 byte packets will pass on the VLANs. But at least > the "dc" driver ignores MTUs larger than 1500. There's some confusion here, because the MTU is typically associated with a protocol stack like IP and refers to the largest sized (IP in this case) packet that can be sent on the network interface. In the case of Ethernet interfaces that support and use VLAN tags, the MTU is still 1500 bytes, regardless of the fact that the frame size is a few bytes longer to accomodate the VLAN tag information. So, this has no effect on the Ethernet type field (or 802.3 length fields) since the higher level protocol packet size is unchanged. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
