Re: scanner problems: I/O error/scanner application hangs
In message [EMAIL PROTECTED], =?ISO-8859-1?Q?Erik_N=F8rgaard?= wr ites: I had my scanner, Epson 2480, working half a year ago on FBSD 6.0, now it's been a while since I used it, I have upgraded to FBSD 6.1-PREREL as well as upgrading applications, and now it doesn't work. Sorry about the breakage - this has been fixed now in -CURRENT and should be merged into 6-stable in the next few days. In the meantime you could apply this patch in /usr/scr/sys/dev/usb: http://people.freebsd.org/~iedowse/savedtoggle.diff Hopefully that should fix the issue - let me know if it doesn't. Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I can't mount my USB thumb drive or ipod -- no /dev/da*
In message [EMAIL PROTECTED], Erin S
harmahd writes:
I'm a bit of a newbie, but I've done a good bit of research, and some
asking around on this issue, and haven't been able to resolve it yet.=20
I'm using FreeBSD 6.0 RELEASE with the GENERIC kernel. (from what i
can tell, it has all of the necessary pieces to allow usb drives).
When I plug my ipod into my computer, dmesg gets the following addition:
umass0: Apple iPod mini, rev 2.00/0.01, addr 2
However, that's all that appears there relative to it. From google, I
found that plugging in an ipod or a usb thumb drive should add a
/dev/da0 (or similar) entry to /dev, which you should mount. I still
don't have a /dev/da*, and I actually checked, and nothing is getting
added to /dev when I plug the ipod in.
Unfortunately a number of Apple iPod devices don't work with 6.0
release. FreeBSD sends a command to the device that causes the iPod
USB interface to get confused and it stops responding. This was
fixed in 6-stable, so you'll need to upgrade or patch the kernel
to get it to work.
You could also just manually remove the offending code. The change
you need to make is in /usr/src/sys/dev/usb/usb_subr.c. Find the
usbd_setup_pipe() function, and then put a '#if 0' and '#endif'
around the code for clearing stall conditions, i.e.:
#if 0
/* Clear any stall and make sure DATA0 toggle will be used next. */
if (UE_GET_ADDR(ep-edesc-bEndpointAddress) != USB_CONTROL_ENDPOINT) {
err = usbd_clear_endpoint_stall(p);
...
return (err);
}
}
#endif
Then recompile and install the kernel, reboot, and the iPod should work.
Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I can't mount my USB thumb drive or ipod -- no /dev/da*
In message [EMAIL PROTECTED], Erin Sharmahd writes: Will this help, even though I can't mount any usb thumb drives or anything like that? It's definitely worth a try. People have reported exactly this issue with both recent iPods, and PNY Attache devices. In the case of the iPods, removing the stall-clearing code was reported to fix the problem, but I don't know whether it will help with the thumb drive. Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dmesg truncated
In message [EMAIL PROTECTED], David Ericks on writes: I've been having this problem for quite a whlie but it's never bothered me too much until I had some free time on my hand to look into it. Is there any kernel parameter that could be truncating my dmesg buffer. Dmesg only seems to have 1 line ever buffered which kinda sucks. I do have a custom kernel built as thin as possible so im thinking that one of the options I may have left out thinking I didn't need it or something along those lines. The message buffer is used to store kernel log messages including console output as well as normal kernel messages; run `dmesg -a' to get the full message buffer contents. Typically these other log messages fill up the buffer so the kernel messages get overwritten. The logging of console output can be useful at boot time, but is often less important later since it is often just syslog messages that are already logged elsewhere. You can arrange for only boot-time console output to be recorded in the message buffer by adding the following line to the end of /etc/rc.local, creating that file if necessary (you could also use /etc/sysctl.conf, but rc.local is better because it happens a bit later): sysctl kern.log_console_output=0 Finally, you can increase the message buffer size by recompiling your kernel with a custom MSGBUF_SIZE setting. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umounting /
In message [EMAIL PROTECTED], Dan Strick writes: You can't unmount the root file system. Even the mere notion makes me feel a little queasy. There is an explicit test in the kernel that stops you from unmounting the root file system, I guess as an anti foot shooting measure. If you disable that test then forcibly unmounting / works fine, but normally init will promptly die because the vnode containing its executable has disappeared. The only case I've come across where the ability to unmount / would be useful is for some kind of rescue or install CD that starts off as the root filesystem but wants to switch over to the real root fs allowing the CD to be removed. I've got this to work before by changing init so that it re-execs itself upon receipt of a special signal. Then you can mount the new root directly over /, send the signal to init, and finally forcibly unmount the underlying /. There are some necessary bits for this that are only in 5.x, such as the ability to unmount by filesystem ID rather than by path. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple USB ethernet devices on one usb port (with hub)?
In message [EMAIL PROTECTED], Andrew Thomas
writes:
I've got an older Dell Latitude (CPi) laptop that I'm trying to
setup as a router/firewall/??? machine. I'm using 5.1-R with a
compiled kernel that I'm slowly reducing to the minimum I need.
I decided to try using usb ethernet adapters since they seemed
so easy. However, the laptop only has one usb port. So, I
picked up a cheap 4 port hub so I could connect my two adapters
(both netgear FA120 devices).
The boot log shows that both devices are recognized. However,
only one gets configured properly (it gets an address and
actually works). The other adapter can't be configured (at
boot time or on the command line). This is whether the devices
are plugged in before booting or after. If I try to remove
either of them after booting I usually get a kernel panic and
a reboot.
Am I trying to do something that can't be done (do I need two
physical ports on the machine for this to work)? Is this
merely a bug in 5.1 that would be fixed if I go to 'CURRENT'?
Does anyone have any comments? For completeness I'm appending
the relevant lines from my config.
Any help would be appreciated.
There is definitely one problem that stops you from using two
identical USB ethernet devices, but I don't know if it's the only
one: the axe driver uses a static (global) stucture for some
per-interface data, so it clobbers this state with two interfaces.
I had said to Bill Paul (cc'd) that I would suggest a patch to fix
this, but I never managed to get my two USB ethernet interfaces in
the same place at the same time to test them! Would you be able to
try out the following patch to see if it helps? Just apply it in
/usr/src and rebuild the kernel.
Thanks,
Ian
Index: sys/dev/usb/if_axe.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/if_axe.c,v
retrieving revision 1.7
diff -u -r1.7 if_axe.c
--- sys/dev/usb/if_axe.c24 Aug 2003 17:55:54 - 1.7
+++ sys/dev/usb/if_axe.c24 Sep 2003 23:26:45 -
@@ -118,8 +118,6 @@
{ 0, 0 }
};
-Static struct usb_qdat axe_qdat;
-
Static int axe_match(device_ptr_t);
Static int axe_attach(device_ptr_t);
Static int axe_detach(device_ptr_t);
@@ -521,8 +519,8 @@
ifp-if_baudrate = 1000;
ifp-if_snd.ifq_maxlen = IFQ_MAXLEN;
- axe_qdat.ifp = ifp;
- axe_qdat.if_rxstart = axe_rxstart;
+ sc-axe_qdat.ifp = ifp;
+ sc-axe_qdat.if_rxstart = axe_rxstart;
if (mii_phy_probe(self, sc-axe_miibus,
axe_ifmedia_upd, axe_ifmedia_sts)) {
@@ -724,7 +722,7 @@
}
ifp-if_ipackets++;
- m-m_pkthdr.rcvif = (struct ifnet *)axe_qdat;
+ m-m_pkthdr.rcvif = (struct ifnet *)sc-axe_qdat;
m-m_pkthdr.len = m-m_len = total_len;
/* Put the packet on the special USB input queue. */
Index: sys/dev/usb/if_axereg.h
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/if_axereg.h,v
retrieving revision 1.2
diff -u -r1.2 if_axereg.h
--- sys/dev/usb/if_axereg.h 15 Jun 2003 21:45:43 - 1.2
+++ sys/dev/usb/if_axereg.h 24 Sep 2003 23:25:52 -
@@ -168,6 +168,7 @@
unsigned char axe_ipgs[3];
unsigned char axe_phyaddrs[2];
struct timeval axe_rx_notice;
+ struct usb_qdat axe_qdat;
};
#if 0
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xclock grows and grows (Was Re: How can I check for swapspace?)
In message [EMAIL PROTECTED], Joh n Mills writes: 'startx' still proceeds until it fills all available memory. In particular, 'top' shows the size of 'xclock' growing while other processes seem OK. ... 2) Does this [mis]behavior sound familiar to anyone? I've seen this before when the fontconfig system got confused. Try running fc-cache -fv as root. If that doesn't fix it, try: echo *clock.render: false /usr/X11R6/lib/X11/app-defaults/XClock This second command disables the Xrender extensions in xclock, which I have found necessary on some systems to make xclock work at all. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB keyboard and KVM
In message [EMAIL PROTECTED], Scott Saunders w rites: I have one issue I haven't been able to figure out yet. I'm using a USB keyboard with a USB KVM switch. When the machine boots, the keyboard is recognized and works fine. (The keyboard doesn't seem to have any effect at the Hit [enter] to boot immediately... line of startup, though.) However, if I switch the KVM to another computer and back, the machine doesn't respond to the keyboard. The monitor comes back fine, but the keyboard and mouse don't seem to do anything. I can log in via SSH, but I would like to turn SSH off and just use the KVM set up. ... I added: kbdcontrol -k /dev/kbd0 /dev/ttyv0 /dev/null to the end of /etc/rc.i386 based on the FAQ. The above command will only run once when the machine boots, so you need to have something that repeats this when the keyboard is (effectively) plugged back in after being removed. Try adding the following lines near the end of /etc/usbd.conf instead: device Keyboard devname ukbd0 attach kbdcontrol -k /dev/kbd0 /dev/ttyv0 On a box that has both a PS/2 and a USB keyboard, I've used an entry like the following to have FreeBSD switch to the USB one when it is plugged in, though this isn't what you want if you only have a USB keyboard. device Keyboard devname ukbd0 attach kbdcontrol -k /dev/kbd1 -r 250.50 /dev/console detach kbdcontrol -k /dev/kbd0 /dev/console Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB keyboard and KVM
In message [EMAIL PROTECTED], Scott Saunders w rites: device Keyboard devname ukbd0 attach kbdcontrol -k /dev/kbd0 /dev/ttyv0 I added this and tried it with and without the kbdcontrol line in /etc/rc.i386. Unfortunately, it doesn't seem to make any difference. It certainly looks to my inexperienced eyes like it should. I can SSH in (and maybe this will be the permanent solution). If I run kbdcontrol -k /dev/kbd0 /dev/ttyv0 while it's 'locked up' I get: kbdcontrol: cannot open /dev/kbd0: Device busy So maybe it didn't close down the connection to the keyboard? If that's anything like how it actually works. I tried plugging the keyboard directly into the machine (not through the KVM) while it was 'locked up', but that had no effect either. Are you using a set up like this, Ian? No, I've only used a setup that had both PS/2 and USB keyboards. Just reading the kbdcontrol man page, the other thing you could try is the -K option to detach the keyboard. e.g: device Keyboard devname ukbd0 attach kbdcontrol -k /dev/kbd0 /dev/ttyv0 detach kbdcontrol -K /dev/ttyv0 (or experiment with kbdcontrol -K from ssh) BTW, what are the last few lines of `dmesg' after the keyboard stops working? Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dangerously dedicated vs. fully dedicated, etc.
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: Mike, I'll pay back your effort in replying to this long thing by working up a patch for the disklabel manpage (at least) and, if you want, I'll CC you so you can veto things you don't like. I do worry At the risk of adding to the confusion, here is a less wordy description of the various disk layouts. The term `dangerously dedicated' seems to be used to refer to either options (B) or (C), so I will avoid using that term: (A) Normal sliced disk (assuming sectors/track = 63) sector 0: boot0 and the DOS slice table sectors 1..62:unused start of slice 1 start of 'a' partition sector 63:boot1 sector 64:disklabel sectors 65-78:boot2 sectors 79-92:'a' partition filesystem superblock Note that the disklabel, which contains a list of the partitions within a slice is actually contained within the space allocated to the first partition. To ensure that this does not get clobbered by the filesystem, the first 8k of every ffs filesystem is reserved for boot code and the disklabel. (B) Dedicated format created by sysinstall start of slice 1 start of 'a' partition sector 0: boot1 and the DOS slice table, where the slice table contains one slice (slice 1) covering the entire disk, including sector 0. sector 1: disklabel sector 2-15: boot2 sectors 16-31:'a' partition filesystem superblock In this case, there is no boot0, and boot1 serves as the boot loader that is invoked by the BIOS. Here, all of the boot code is contained within the first slice and also within the first partition. Again, the 8k reserved at the start of every ffs filesystem protects the boot code. Sysinstall sets up fstab to refer to the partitions as e.g. /dev/ad0s1a (I think). (C) Dedicated format using dummy slice start of slice 4 start of 'a' partition sector 0: boot1 and the DOS slice table. The slice table contains a single entry (slice 4) that starts at sector 0 and has a size of 5 sectors, whatever the real disk size is. sector 1: disklabel sector 2-15: boot2 sectors 16-31:'a' partition filesystem superblock This is like (B) except that slice 4 instead of slice 1 is used, and the size of the slice in the slice table is bogus. The partitions on such a disk are usually accessed using the compatibility slice names such as /dev/ad0a. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Dangerously dedicated vs. fully dedicated, etc.
In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes: /boot/boot0 has the FreeBSD bootloader. The installer also offers to use the standard /boot/mbr. Roughly speaking. /boot/boot2 is 15 sectors; I suppose the first (all zeros) is replaced with the disklabel, loosely speaking. One such as would be created by disklabel -B. (/boot/boot1 seems to have the fourth slice pre-defined.) This differs from B only in the slice table, right? The disklabel manpage implies that this is a DD. Exactly. Thanks for filling in the details I missed. The other magic thing about the bogus 5-sector slice is that the kernel detects this special case and then completely ignores the slice table and makes the compatibility slice cover the whole disk (I'm not 100% sure of the details here). It seems that a DD disk is one which is similar to a single slice starting at sector 0, regardless of what the slice table part of sector 0 contains. With FreeBSD-standard boot code and some BIOSes, one disk layout (ie, DD or sliced) will work better than the other. (And for DD disks, some slice table contents might work better than others. I've not read anything comparing your B and C or either with a slice table full of zeros or random bits.) I think to avoid warnings or errors, you need either a valid slice entry (even if it is a sysinstall-style slice that starts at sector 0 and contains the whole disk), or else the exact special bogus slice table, since the kernel code just does a bcmp() to check for the special bogus table. As to the issue of BIOSes disliking DD modes, there have been a few different reasons suggested. For traditional BIOSes that just look for the 0x55 0xaa signature and if found then execute the MBR code, all of the various DD and non-DD schemes should work fine. However, some BIOSes perform additional tests that may fail on DD disks. For example (I'm just guessing here), they might check that the slice starts after the MBR, or that the slice starts and ends on a cylinder boundary. It sounds a silly thing to do, but I guess maybe it allows the BIOS to automatically figure out what geometry the OS is expecting or something. The fact that boot1 always contains the bogus slice table even when boot1 is not used as an MBR has been linked to other BIOS problems too - some BIOSes apparently go further and check if the first sector of each slice looks like it has an extended partition table even if the slice type is not that of an extended partition. In -CURRENT, the default bogus slice table was changed slightly to stop some BIOSes crashing with a divide-by-zero error when they tried to parse the bogus slice entry in boot1. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: Regarding one important issue
In message [EMAIL PROTECTED], Senthil writes: Hi, We are using FreeBSD in our organization as a NFS Server. Latest, we have developed a NFS client on Windows, we are facing some problem with NFSRead on Version 3. Basically we request for reading some size of bytes, (which is the read Maximum number of bytes returned by stat information(deliberately we are not asking read preferred number of bytes ). But FreeBSD NFS Server is retuning a error as garbled arguments. I can have a look if you can get a complete tcpdump log of the request and the response that you saw. Use tcpdump options that capture the full packets such as: tcpdump -nepX -s 1600 udp port 2049 Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: devbuf state in top
In message [EMAIL PROTECTED], Chris Ptacek writes: I had a process whose state under top was listed as devbuf. This process seemed to be stuck and I was unable to kill it. I ended up rebooting the box to reset it. None of the man pages (TOP, PS) list the devbuf state. What is it and what was the process trying to do? I am guessing it had something to do with memory allocation. It means that the kernel is trying to allocate memory with a type code of M_DEVBUF, but the kernel limit for that type has been reached. Hence the process is stuck waiting for something to free M_DEVBUF memory for it to use. `vmstat -m' shows the current amount of memory allocated by each malloc type. As the name suggests M_DEVBUF is normally used for buffers in kernel devices. Maybe you have created a very large number of devices or configured a device in a way that requires a lot of memory (e.g set a huge value for SC_HISTORY_SIZE), maybe there is a memory leak, or possibly you just need to increase the value of MAXUSERS in the kernel configuration file. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: accept() doesn't pass back sockaddr
In message [EMAIL PROTECTED], Christopher Weimann writes: I am using on a web filter ( dansguardian.org ) and am having problems on FreeBSD (4.5-STABLE). The filter runs fine for about 20 minutes or so then can't seem to come up with the right ip addresses for any client machines. After much reading of man pages, Stevens, and some banging of my head against the desk I decided that maybe it wasn't me :) I found a PR that I think seems to relate (misc/34307) but this still confuses me. I would think that if the situation this PR describes were to be the case all sorts of things wouldn't be working right. Is the code in question correctly initialising the variable that the `addrlen' parameter points to before calling accept? It looks as if this might be the problem in the PR you mention. I mean that the code should look like sin_len = sizeof(sin); s = accept(servsock, (struct sockaddr *)sin, sin_len); where `sin_len' is reset to the correct length before calling accept() each time. I think sin_len may be reset to 0 when an error occurs, but otherwise you would get away with not resetting it. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: NIS/YP -NFS -DISKLESS problem, weird
In message [EMAIL PROTECTED], Hartmann, O. writes: I can see the X-Terminals and other diskless systems booting but when mounting / via NFS from the boot host, they get stuck. It seems that they can not mount the NFS file system, but that is not the problem. I exported then the root tree of the diskless systems to another system and I saw that they can mount it without any problem. But now the weird thing comes into play: I can travers via cd and ls __all__ directories and can list all dir entries execept those of etc! Hi, Could you collect a tcpdump trace of the client as it becomes stuck? Something like tcpdump -nepX -s 1600 host your_client_ip and udp port 2049 run from the server should do the trick. I just need to see a few retransmits of the failing request. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
