Re: Serial debug broken in recent -CURRENT?
On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: After building a new kernel, remote serial gdb no longer works. When I issue a 'continue' command, I lose control of the system, but it doesn't continue running. Has anybody else seen this? It works as well as it did a few months ago here. (Not very well compared with ddb. E.g., calling a function is usually fatal.) Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: more panics from current (partII)
Once again our vinum build failed. This time it could do over 90% of 14 hours of work and we didn't got a panic just a hang. Only we could do while system was printing ata error messages was to press reset button. Difference to earlier situation is that we put back old 3c905 xl-card and removed 4 port dc-Znyx. At the same time we changed pci card positions. Do you still think this has nothing do ata kernel code? Tomppa login: ad6: WARNING - WRITE_DMA recovered from missing interrupt ad6: WARNING - WRITE_DMA recovered from missing interrupt ad6: WARNING - WRITE_DMA recovered from missing interrupt ad4: WARNING - WRITE_DMA recovered from missing interrupt ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ad6: WARNING - WRITE_DMA recovered from missing interrupt ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ata2: spurious interrupt - status=0x51 error=0x84 reason=0x01 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2706] Re: Odd ACPI behavior
On Mon, 29 Sep 2003, Nate Lawson wrote: On Mon, 29 Sep 2003, Kevin Oberman wrote: ACPI attaches the bus twice. See sys/dev/acpica/acpi.c: Thanks. That explains why I get the message twice, but why do I get it at all when the device is disabled in the device.hints file? Dunno. That's probably an sio(4) problem. It does that on my laptop also. It would be a layering violation for sio(4) to even look at the disabled flag. However, it has to look at this flag for consoles, since new-bus is is not initialized when consoles are attached. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [acpi-jp 2705] Re: Odd ACPI behavior
On 2003-09-29 13:33:06 (-0700), Nate Lawson [EMAIL PROTECTED] wrote: On Mon, 29 Sep 2003, Kevin Oberman wrote: From: John Baldwin [EMAIL PROTECTED] On 29-Sep-2003 Kevin Oberman wrote: I recently noticed that, when I boot with ACPI on my IBM T30, I get errors trying to probe the BIOS disabled sio1. This does not happen under apm and happens twice(?) when booting with ACPI and happens even though I have the line 'hint.sio.1.disabled=1' in /boot/device.hints. Do you kldload a module at some point during your boot? If so, that would explain the double probe. Yes, it would, but I am not loading any kernel modules except the slightly automatic loads of ACPI, itself and a few others which should not cause a probe: ntfs, linux, linprocfs, and daemon_saver. ACPI attaches the bus twice. See sys/dev/acpica/acpi.c: There's a bit more weirdness in this regard. I think the ACPI attaching twice is part of the story, but it doesn't appear to be all. As far as I can tell, it's also to do with acpi attaching after something else is already attached. The really funny thing is that acpi tries to attach (twice?) every time the module is 'tickled' in some way. Using my acpi_asus driver as an example: Just booting the machine with acpi and my module loading after the kernel: Preloaded elf kernel /boot/kernel/kernel at 0xc04fc000. [...] Preloaded elf module /boot/kernel/acpi_asus.ko at 0xc04fc374. Preloaded elf module /boot/kernel/acpi.ko at 0xc04fc424. For some reason, acpi always insists on being the last module loaded. That might be something in my configuration though? It's slightly annoying as acpi_asus depends on acpi. Then we get the first acpi attachment, which for some reason always fails on me: sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled A bit later, there's the second attachment, which works, but complains about a nonexistent sio: sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled When I unload the acpi_asus module, nothing funny happens, when I reload it, however: sio4: configured irq 3 not in bitmap of probed irqs 0 sio4: port may not be enabled It appears as though 2 and 3 are skipped because they're marked as disabled in device.hints. Funny that it doesn't try a sio4 at boottime, only if it's loaded after acpi is already present. When I boot, acpi_asus loads before acpi, complaining that it needs acpi, and loads it, then acpi tries to load, complaining that it's already there. Then we get the mysterious sio1, which doesn't exist, popping up. Very odd stuff, I've been looking into this, but as it's not really a problem (everything works), I've not looked too hard yet :-) - Philip [of course, I might be very wrong :-)] -- Philip Paeps Please don't CC me, I am subscribed to the list. BOFH Excuse #166: /pub/lunch ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serial debug broken in recent -CURRENT?
On Tuesday, 30 September 2003 at 16:23:35 +1000, Bruce Evans wrote: On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: After building a new kernel, remote serial gdb no longer works. When I issue a 'continue' command, I lose control of the system, but it doesn't continue running. Has anybody else seen this? It works as well as it did a few months ago here. (Not very well compared with ddb. E.g., calling a function is usually fatal.) Hmm, that's not what Sam or I are seeing. How old is your kernel? You *are* able to continue, right? Everything else works for me. Greg -- See complete headers for address and phone numbers. NOTE: Due to the currently active Microsoft-based worms, I am limiting all incoming mail to 131,072 bytes. This is enough for normal mail, but not for large attachments. Please send these as URLs. pgp0.pgp Description: PGP signature
Re: SiL3112 SATA (RAID) Controller drives aren't working at all.
My troublesome system uses an Adaptec Serial ATA RAID 1210SA which has the SiI3112 RAID chip. I have only one drive connected, so no RAID functionality. Here is my verbose dmesg using the 9/28/03 snapshot: http://www.computinginnovations.com/dmesg.html -Derek At 12:38 PM 9/29/2003 -0700, Will Andrews wrote: On Mon, Sep 29, 2003 at 09:13:48PM +0200, Soren Schmidt wrote: First off, there is ONLY support for Promise and HPT soft RAID in the ATA driver, other vendors products are *not* supported (yet). Second, there seem to be a problem with some sil3112 setups where timeouts and what not ruins the lunch, but so far I've not been able to reproduce.. I am still unable to use my SATA drive, it's probed incorrectly as I posted earlier. Reverting to the August 10th 00:00 UTC kernel fixes this problem, so I concluded that ATAng broke this. If it makes any difference, my model is a SiI3112 RAID controller, but I only have one drive and it probes as ad4... the situation doesn't improve any if I add ataraid. But maybe ATAng doesn't take into account the difference between a normal and a RAID SiI 3112, if any? Here are my dmesg's again (Sep 18th, Aug 10th kernels): http://csociety.org/~will/dmesg.badATAng http://csociety.org/~will/dmesg.Aug10.preATAng The problem shown in the first dmesg still showed itself when I tried a new kernel on Sep 25th. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with geom_bde
In message [EMAIL PROTECTED], Thorsten Greiner writes : Hi, inspired by the recent posting of the gbde tutorial I went out and set up an encrypted partition using geom_bde on my laptop. When trying to umount this partition the umount fails with: # umount /crypto umount: unmount of /crypto failed: Resource temporarily unavailable Did you call gbde detach before the umount ? You need to unmount first. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: SiL3112 SATA (RAID) Controller drives aren't working at all.
Hi Derek Ragona, you wrote. DR My troublesome system uses an Adaptec Serial ATA RAID 1210SA which has the DR SiI3112 RAID chip. I have only one drive connected, so no RAID functionality. DR Here is my verbose dmesg using the 9/28/03 snapshot: DR http://www.computinginnovations.com/dmesg.html My 28.8.03 JPSNAP (i.e. current.freebsd.org) box with two Maxtor 120 GB SATA drives connected to the Sil3112 chip will probe both disks ok, comes up normally but shortly thereafter goes under in a bunch of UDMA timeouts. I can provide dmesg later today if that is of any worth. Regards, Gabriel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with geom_bde
* Poul-Henning Kamp [EMAIL PROTECTED]: Did you call gbde detach before the umount ? No. You need to unmount first. Yes, that's what I tried. I then get the fsync: giving up on dirty message. When I shut down the box, it tries to sync the dirty buffers and finally says giving up on 2 buffers, leaving all my filesystems dirty, and corrupted data on the gbde device (lots of zero bytes in files). Regards -Thorsten __ Bestes Testergebnis: Stiftung Warentest Doppelsieg fur WEB.DE FreeMail und WEB.DE Club. Nur fuer unsere Nutzer! http://f.web.de/?mc=021182 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serial debug broken in recent -CURRENT?
On Tue, 30 Sep 2003, Greg 'groggy' Lehey wrote: On Tuesday, 30 September 2003 at 16:23:35 +1000, Bruce Evans wrote: On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: After building a new kernel, remote serial gdb no longer works. When I issue a 'continue' command, I lose control of the system, but it doesn't continue running. Has anybody else seen this? It works as well as it did a few months ago here. (Not very well compared with ddb. E.g., calling a function is usually fatal.) Hmm, that's not what Sam or I are seeing. How old is your kernel? You *are* able to continue, right? Everything else works for me. I didn't test with my kernel; I tested with almost-current SMP and !SMP kernels (amost-current = 217 lines of patches; my kernel = 96934 lines of patches). They were about half an hour old when I tried it. I tested little more than continuing from Debugger(). I didn't test using optional foot shooting devices like acpi or modules. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Status of SCHED_ULE?
On Mon, 29 Sep 2003, Jeff Roberson wrote: Are you running seti, rc4, etc? Any programs that sit in the background and consume 100% of the cpu? I'm running KDE (using libc_r), and run setiathome and/or dnetc in the background. I've also tried killing the background tasks, but it makes little difference. I also use moused and /dev/sysmouse for X. I've even tried renicing moused to negative nice values, and that doesn't change much either. The mouse gets 'sticky' under moderate/heavy load, as other people have described. I haven't swapped back to SCHED_4BSD recently to compare, but I'm sure it was smoother before I switched. -- David Taylor [EMAIL PROTECTED] The future just ain't what it used to be ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
question about src/etc/Makefile
Hi,
I don't understand why boot/device.hints are installed with
distribute target instead distribution, in the Makefile:
# $FreeBSD: src/etc/Makefile,v 1.313 2003/05/06 07:25:17 dougb Exp $
I build FreeBSD-4.8 with a shell script near like this:
export DESTDIR=/usr/src/dest/fbsd-48
export KERNCONF=SMP
cd /usr/src make world
cd /usr/src/etc make distribution
cd /usr/src make buildkernel installkernel
I'll try to do the same thing with FreeBSD-5.1 but buildkernel fails
because make distribution doesn't install boot/device.hints in $DESTDIR.
/usr/sbin/mergemaster use distribution target too:
{ cd ${SOURCEDIR}
case ${DESTDIR} in
'') ;;
*)
make DESTDIR=${DESTDIR} distrib-dirs
;;
esac
make DESTDIR=${TEMPROOT} distrib-dirs
make MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj obj
make MAKEOBJDIRPREFIX=${TEMPROOT}/usr/obj DESTDIR=${TEMPROOT} \
distribution;} ||
Is-it an error in src/etc/Makefile ?
Or may I have to use distribute target instead distribution ?
Luc.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
wicontrol TX patch
Hello
My questoin is about status of wicontrol TX power control in current ?
Anybody planing to commit it into wicontrol ?
I use modified patch from imp for three months
it works well, but problem is, that if card is reseted by wi_reset - i
guess,
value from register is owerwrited by default (I think ALC also turns on)
any ideas/solutions how keep this TX power value after card reset ?
for this time I use cron to periodicaly refresh TX power ..
sorry for my english ;)
thaks for reply
Jiri
--- usr.sbin/wicontrol/wicontrol.c Tue Sep 30 00:55:25 2003
+++ usr.sbin/wicontrol/wicontrol.c Tue Sep 30 12:54:26 2003
@@ -1070,6 +1070,135 @@
opt);
}
+/* TX Power patch */
+static void
+wi_setdebug(const char *iface, struct wi_req *wreq)
+{
+ struct ifreqifr;
+ int s;
+
+ bzero((char *)ifr, sizeof(ifr));
+
+ strlcpy(ifr.ifr_name, iface, sizeof(ifr.ifr_name));
+ ifr.ifr_data = (caddr_t)wreq;
+
+ s = socket(AF_INET, SOCK_DGRAM, 0);
+
+ if (s == -1)
+ err(1, socket);
+
+ if (ioctl(s, SIOCSPRISM2DEBUG, ifr) == -1)
+ err(1, SIOCSPRISM2DEBUG);
+
+ close(s);
+
+ return;
+}
+
+#if 0
+static void
+wi_getdebug(const char *iface, struct wi_req *wreq)
+{
+ struct ifreqifr;
+ int s;
+
+ bzero((char *)ifr, sizeof(ifr));
+
+ strlcpy(ifr.ifr_name, iface, sizeof(ifr.ifr_name));
+ ifr.ifr_data = (caddr_t)wreq;
+
+ s = socket(AF_INET, SOCK_DGRAM, 0);
+
+ if (s == -1)
+ err(1, socket);
+
+ if (ioctl(s, SIOCGPRISM2DEBUG, ifr) == -1)
+ err(1, SIOCGPRISM2DEBUG);
+
+ close(s);
+
+ return;
+}
+#endif
+
+/* Map HFA386x's CR31 to and from dBm with some sort of ad hoc mapping..
+ * This version assumes following mapping:
+ * CR31 is 7-bit value with -64 to 63 range.
+ * -64 is mapped into 20dBm and 63 into -43dBm.
+ * This is certainly not an exact mapping for every card, but at least
+ * increasing dBm value should correspond to increasing TX power.
+ */
+
+static int
+wi_txpower_to_dBm(uint16_t val)
+{
+ signed char tmp;
+
+ if (val 255)
+ val = 255;
+
+ tmp = val;
+ tmp = 2;
+
+ return -12 - tmp;
+}
+
+#if 0
+static uint16_t
+wi_dBm_to_txpower(int val)
+{
+ signed char tmp;
+
+ if (val 20)
+ return 128;
+ else if (val -43)
+ return 127;
+
+ tmp = val;
+ tmp = -12 - tmp;
+ tmp = 2;
+
+ return (unsigned char) tmp;
+}
+#endif
+
+static void
+wi_readpower(const char *iface)
+{
+ struct wi_req wreq;
+
+ printf(reading power\n);
+
+ wreq.wi_type = WI_RID_MIF;
+ wreq.wi_val[0] = WI_HFA386X_CR_MANUAL_TX_POWER;
+ wreq.wi_len = 1 + 1;
+
+ wi_getval(iface, wreq);
+ printf(Value returned was 0x%x or %d dBm\n, wreq.wi_val[0],
+ wi_txpower_to_dBm(wreq.wi_val[0]));
+}
+
+static void
+wi_writepower(const char *iface, int power)
+{
+ struct wi_req wreq;
+
+ wreq.wi_type = WI_RID_MIF;
+ wreq.wi_val[0] = WI_HFA386X_CR_MANUAL_TX_POWER;
+ wreq.wi_val[1] = power;
+ wreq.wi_len = 1 + 1 + 1;
+ wi_setval(iface, wreq);
+
+ wreq.wi_type = WI_DEBUG_CONFBITS;
+ wreq.wi_val[0] = 0;
+ wreq.wi_val[1] = 0x8;
+ wreq.wi_len = 1 + 1 + 1;
+ wi_setdebug(iface, wreq);
+
+}
+
+/* TX Power patch end */
+
int
main(int argc, char *argv[])
{
@@ -1097,8 +1226,20 @@
opterr = 1;
while((ch = getopt(argc, argv,
- a:c:d:e:f:hi:k:lm:n:op:q:r:s:t:v:CF:LP:QS:T:Z)) != -1) {
+ /* Patched ARGS for tx power (AB added) */
+ /* old: a:c:d:e:f:hi:k:lm:n:op:q:r:s:t:v:CF:LP:QS:T:Z)) != -1) { */
+ a:c:d:e:f:hi:k:lm:n:op:q:r:s:t:v:AB:CF:LP:QS:T:Z)) != -1) {
switch(ch) {
+ /* TX Power patch */
+ case 'A':
+ wi_readpower(iface);
+ exit(0);
+ break;
+ case 'B':
+ wi_writepower(iface, atoi(optarg));
+ exit(0);
+ break;
+ /* TX Power patch end */
case 'Z':
#ifdef WICACHE
wi_zerocache(iface);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X10 Wireless Technology Inc USB Receiver
On Sun, Sep 21, 2003 at 07:24:48PM -0700, Lars Eggert wrote: Bernd, Bernd Walter wrote: What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say? it says this: usbd_setup_pipe: dev=0xc3f9d980 iface=0xc3efbaa0 ep=0xc3f192c8 pipe=0xdb936974 ugenwrite: transfer 5 bytes usbd_intr_transfer: start transfer 5 bytes usbd_intr_transfer: transferred 0 usbd_intr_transfer: error=13 Can you please do this again with additionaly hw.usb.ohci.debug=10 set. error=13 makes me believe that this could be a OHCI driver problem. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
is 5.1 now more stable than 4.9rc
It just seems that there are alot of issues w/ 4.9, doesn't seem stable at all. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: X10 Wireless Technology Inc USB Receiver
Bernd Walter wrote: Can you please do this again with additionaly hw.usb.ohci.debug=10 set. error=13 makes me believe that this could be a OHCI driver problem. Here you go: Sep 30 08:49:49 host192 kernel: usbd_setup_pipe: dev=0xc3f66c00 iface=0xc3ee5e80 ep=0xc3eee458 pipe=0xdd0a3974 Sep 30 08:49:49 host192 kernel: ohci_open: pipe=0xc4b89780, addr=5, endpt=2 (1) Sep 30 08:49:49 host192 kernel: ohci_setintr: pipe=0xc4b89780 Sep 30 08:49:49 host192 kernel: ohci_setintr: ival=10 npoll=8 Sep 30 08:49:49 host192 kernel: ohci_setintr: best=10(7..15) bestbw=0 Sep 30 08:49:49 host192 kernel: ohci_setintr: returns 0xc4b89780 Sep 30 08:49:49 host192 kernel: ohci_device_control type=0x02, request=0x01, wValue=0x, wIndex=0x0002 len=0, addr=5, endpt=0 Sep 30 08:49:49 host192 kernel: ohci_device_request: Sep 30 08:49:49 host192 kernel: ED(0xc3f6e700) at 0x008e2700: addr=5 endpt=0 maxp=8 flags=82005LOWSPEED Sep 30 08:49:49 host192 kernel: tailp=0x008e1e40 headflags=8e1e40 headp=0x008e1e40 nexted=0x008e2720 Sep 30 08:49:49 host192 kernel: TD(0xc3f6de40) at 008e1e40: f2e0SETTOGGLE delay=7 ec=0 cc=15 Sep 30 08:49:49 host192 kernel: cbp=0x00908e00 nexttd=0x008e1db0 be=0x00908e07 Sep 30 08:49:49 host192 kernel: TD(0xc3f6ddb0) at 008e1db0: f330IN,TOG1,SETTOGGLE delay=1 ec=0 cc=15 Sep 30 08:49:49 host192 kernel: cbp=0x nexttd=0x008e1e70 be=0x Sep 30 08:49:49 host192 kernel: TD(0xc3f6de70) at 008e1e70: 0 delay=0 ec=0 cc=0 Sep 30 08:49:49 host192 kernel: cbp=0x nexttd=0x be=0x Sep 30 08:49:49 host192 kernel: ohci_intr: sc=0xc3f71000 intrs=0x6(0x0) eintrs=0x2 Sep 30 08:49:49 host192 kernel: ugenwrite: transfer 5 bytes Sep 30 08:49:49 host192 kernel: usbd_intr_transfer: start transfer 5 bytes Sep 30 08:49:49 host192 kernel: ohci_device_intr_transfer: xfer=0xc56c4900 len=5 flags=0 priv=0 Sep 30 08:49:49 host192 kernel: ohci_device_intr_transfer: Sep 30 08:49:49 host192 kernel: ED(0xc3f6e6c0) at 0x008e26c0: addr=5 endpt=2 maxp=8 flags=82105LOWSPEED Sep 30 08:49:49 host192 kernel: tailp=0x008e1f90 headflags=8e1f90 headp=0x008e1f90 nexted=0x008e2f00 Sep 30 08:49:49 host192 kernel: TD(0xc3f6df90) at 008e1f90: f030IN delay=1 ec=0 cc=15 Sep 30 08:49:49 host192 kernel: cbp=0x00908d00 nexttd=0x008e1db0 be=0x00908d04 Sep 30 08:49:49 host192 kernel: TD(0xc3f6ddb0) at 008e1db0: 0 delay=0 ec=0 cc=0 Sep 30 08:49:49 host192 kernel: cbp=0x nexttd=0x be=0x Sep 30 08:49:49 host192 kernel: ohci_intr: sc=0xc3f71000 intrs=0x6(0x0) eintrs=0x2 Sep 30 08:49:49 host192 kernel: usbd_intr_transfer: transferred 0 Sep 30 08:49:49 host192 kernel: usbd_intr_transfer: error=13 Sep 30 08:49:49 host192 kernel: ohci_device_control type=0x02, request=0x01, wValue=0x, wIndex=0x0002 len=0, addr=5, endpt=0 Sep 30 08:49:49 host192 kernel: ohci_device_request: Sep 30 08:49:49 host192 kernel: ED(0xc3f6e700) at 0x008e2700: addr=5 endpt=0 maxp=8 flags=82005LOWSPEED Sep 30 08:49:49 host192 kernel: tailp=0x008e1e70 headflags=8e1e70 headp=0x008e1e70 nexted=0x008e2720 Sep 30 08:49:49 host192 kernel: TD(0xc3f6de70) at 008e1e70: f2e0SETTOGGLE delay=7 ec=0 cc=15 Sep 30 08:49:49 host192 kernel: cbp=0x00908e00 nexttd=0x008e1f90 be=0x00908e07 Sep 30 08:49:49 host192 kernel: TD(0xc3f6df90) at 008e1f90: f330IN,TOG1,SETTOGGLE delay=1 ec=0 cc=15 Sep 30 08:49:49 host192 kernel: cbp=0x nexttd=0x008e1e40 be=0x Sep 30 08:49:49 host192 kernel: TD(0xc3f6de40) at 008e1e40: 0 delay=0 ec=0 cc=0 Sep 30 08:49:49 host192 kernel: cbp=0x nexttd=0x be=0x Sep 30 08:49:49 host192 kernel: ohci_intr: sc=0xc3f71000 intrs=0x6(0x0) eintrs=0x2 Sep 30 08:49:49 host192 kernel: ohci_device_intr_close: pipe=0xc4b89780 nslots=4 pos=10 Sep 30 08:49:49 host192 kernel: ohci_intr: sc=0xc3f71000 intrs=0x6(0x0) eintrs=0x2 Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: is 5.1 now more stable than 4.9rc
On Tue, Sep 30, 2003 at 11:52:05AM -0400, Eriq Lamar wrote: It just seems that there are alot of issues w/ 4.9, doesn't seem stable at all. The answer is probably no. Of course, your vague statement about 4.9 not being stable makes it hard to judge whether 5.1 is a better choice than 4.9. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serial debug broken in recent -CURRENT?
On Tuesday 30 September 2003 04:01 am, Bruce Evans wrote: On Tue, 30 Sep 2003, Greg 'groggy' Lehey wrote: On Tuesday, 30 September 2003 at 16:23:35 +1000, Bruce Evans wrote: On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: After building a new kernel, remote serial gdb no longer works. When I issue a 'continue' command, I lose control of the system, but it doesn't continue running. Has anybody else seen this? It works as well as it did a few months ago here. (Not very well compared with ddb. E.g., calling a function is usually fatal.) Hmm, that's not what Sam or I are seeing. How old is your kernel? You *are* able to continue, right? Everything else works for me. I didn't test with my kernel; I tested with almost-current SMP and !SMP kernels (amost-current = 217 lines of patches; my kernel = 96934 lines of patches). They were about half an hour old when I tried it. I tested little more than continuing from Debugger(). I didn't test using optional foot shooting devices like acpi or modules. It reliably locks up for me when you break into a running system; set a breakpoint; and then continue. Machine is UP+HTT. Haven't tried other machines. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bluetooth patch
John, [...] : Julian and Ruslan are busy at the moment. M. Warner Losh has sent e-mail : to core@ and asked for commit bit for me. in the mean time i'd like to : commit this and resolve all issues in time for 5.2-RELEASE. : : I can give it a go if no one else wants to do it. [...] However, if you'd like to help review the changes before/as they go into the tree, my feelings won't be hurt :-) If you need help time wise I'd be happy to help. the revised version of the patch can be downloaded from http://www.geocities.com/m_evmenkin/patch/bluetooth20030930.diff.gz i think, i fixed all the issues you found. please review and let me know if there are any problems. thanks, max __ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATAng not detecting primary slave device
Hello All, I set up a box (FreeBSD 5.1-CURRENT #0: Tue Sep 23 00:21:31 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC, compiled from the sources the day before) showing the erratic behaviour. Verbose boot logs are available at http://cheasy.dyndns.org/bootlogs/ . If anybody (Søren?) is interested in access to the box to debug this beast, please contact me. Thanks for the good work so far -Christoph Sold ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bluetooth patch
On Mon, Sep 29, 2003 at 10:51:56PM +0200, John Hay wrote: i see, is that a problem? i can clean up the patch and remove these entries. (frankly i thought CVS should take care of it). I don't think it will break cvs, it might just cause some extra bloat. Maybe just get rid of those parts of the patch where the only change to the file is the $FreeBSD$ line? We have CVS magic that unexpands the $FreeBSD$ on it's way back into the repo. It might complain that it is invalid, but it shouldn't cause any repo bloat. pgp0.pgp Description: PGP signature
Re: is 5.1 now more stable than 4.9rc
From: Eriq Lamar [EMAIL PROTECTED] Date: Tue, 30 Sep 2003 11:52:05 -0400 Sender: [EMAIL PROTECTED] It just seems that there are alot of issues w/ 4.9, doesn't seem stable at all. Yes, but there are a lot of issues in 5.1, too. And some are the same ones. The ATAng issues are hitting both 4.9 and 5.1 about (but not quite) the same way. The PAE issues seem to be resolved in 4.9 and have long since been resolved in 5.1. The sudden reboot syndrome (which is unusual but now does not seem to be rare) looks like a 4.9 issue, but it may be that just not enough people are running 5.1. At least some folks are now managing to get some tracebacks and dumps. 5.1 has a lot of very different issues, but those running it have learned to live with them and work around them. CURRENT is getting pretty stable, but, by its nature, has times of VERY unstable behavior. It's certainly not something to run on a system that you want to be very stable. At least that's my view of it. (I have been running current for about a year, so I may be a bit inured to some of its issues.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem w/ ACPI in -CURRENT: Update
In my continuing quest to figure out what's wrong with ACPI in -CURRENT on my laptop, I've tried going back to the old ata drivers (worked, but made no difference), ended up blowing my computer up (weird fsck problem crept in), went back to 5.1, moved up to -CURRENT again, and started plugging away at this problem again. I'm still not sure what's causing it, but I think I've found where it's hanging now: acpi_cmbat_get_bif() in acpi_cmbat.c. I'm putting more debugging statements into that file to see if I can narrow down exactly where it's hanging, but it looks like the problem is somewhere in there. Any ideas what I should be looking for? -j -- /* You are not expected to understand this. */ Captain_Tenille http://www.satanosphere.com/ [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
SiI3112 SATA controller problems - status
I have now found a way to reproduce the DMA problems some setups seems to be having with the SiI3112A SATA chip. Now, if I use real SATA drives, (and I mean real SATA drives, the WD Raptor fx is not a real SATA device but just a PATA device with a build in PATA-SATA converter chip) it works just fine no matter what I try. If however I use an older PATA drive and a certain PATA-SATA dongle (in this case 1 out of 4 samples) I can reproduce the problem pretty easily. This suggests to me that we are looking at a timing problem of sorts the question is where. I'll work on the problem as time permits... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serial debug broken in recent -CURRENT?
Sam Leffler writes: It reliably locks up for me when you break into a running system; set a breakpoint; and then continue. Machine is UP+HTT. Haven't tried other machines. Perhaps related, perhaps a red-herring: With a single P4 + HTT, + SMP kernel, if I break into the ddb debugger on a serial console, the machine locks solid about 1 in 4 times. This is with a kernel from mid August. I have been too busy / too wimpy to upgrade past ATAng. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiI3112 SATA controller problems - status
On Tue, Sep 30, 2003 at 10:06:40PM +0200, Soren Schmidt wrote: I have now found a way to reproduce the DMA problems some setups seems to be having with the SiI3112A SATA chip. Now, if I use real SATA drives, (and I mean real SATA drives, the WD Raptor fx is not a real SATA device but just a PATA device with a build in PATA-SATA converter chip) it works just fine no matter what I try. Interesting. SATA is also a power spec, right? I use a normal SATA cable but also an ATX power connector. I'm guessing that's what you mean by the Raptor not being a real SATA drive. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng panic?
I have been getting a similar panic for several weeks now. I cvsup-ed and built a new kernel yesterday (9/29) and it still doesn't see it. This is with a SIS 630 chipset UDMA controller. --- Tilman Linneweh [EMAIL PROTECTED] wrote: Hi, Updated my -CURRENT yesterday and got the following panic: [...] atapci0: AcerLabs Aladdin UDMA33 controller port 0xb800-0xb80f at device 15.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A, console sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: Option ROM at iomem 0xc-0xc7fff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x100 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 400910809 Hz quality 800 Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. GEOM: create disk ad0 dp=0xc18eec70 ad0: 8063MB IBM-DHEA-38451 [16383/16/63] at ata0-master UDMA33 ad0: WARNING - READ_DMA recovered from missing interrupt GEOM: create disk ad1 dp=0xc18eee70 ad1: 19541MB Maxtor 92041U4 [39703/16/63] at ata0-slave UDMA33 acd0: CDROM CD-ROM 56X/AKH at ata1-slave PIO4 Waiting 15 seconds for SCSI devices to settle ad0: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt ad1: WARNING - READ_DMA recovered from missing interrupt cd0 at sym0 bus 0 target 4 lun 0 cd0: PLEXTOR CD-R PX-R820T 1.06 Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed ad1: WARNING - READ_DMA recovered from missing interrupt Mounting root from ufs:/dev/ad0s1a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: fstype:device Mount device using filesystem fstype eg. ufs:da0s1a ? List valid disk boot devices empty line Abort manual input mountroot ? panic: Root mount failed, startup aborted. Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db where Debugger(c041b1ac,c04a4560,c042237c,c8921c8c,100) at Debugger+0x54 panic(c042237c,c0235770,c0b80d3c,c8921d0c,c02357db) at panic+0xd5 vfs_mountroot(c04a28a0,1,c0417f4b,218,0) at vfs_mountroot+0xce start_init(0,c8921d48,c0418c4e,314,0) at start_init+0x6b fork_exit(c0235770,0,c8921d48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc8921d7c, ebp = 0 --- A working version looks like this: FreeBSD 5.1-CURRENT #1: Sat Aug 16 10:11:52 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/source/CURRENT/sys/POLLY Preloaded elf kernel /boot/kernel.safe/kernel at 0xc0583000. Preloaded elf module /boot/kernel.safe/acpi.ko at 0xc05831fc. Timecounter i8254 frequency 1193182 Hz CPU: AMD-K6(tm) 3D processor (400.91-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x58c Stepping = 12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x8800SYSCALL,3DNow! real memory = 134201344 (127 MB) avail memory = 124452864 (118 MB) K6-family MTRR support enabled (2 registers) npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P5A on motherboard pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00f0d00 acpi0: power button is handled as a fixed feature programming model. acpi_cpu0: CPU port 0x530-0x537 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 9 INTA is routed to irq 9 pcib0: slot 11 INTA is routed to irq 10 pcib0: slot 12 INTA is routed to irq 11 pcib0: slot 13 INTA is routed to irq 9 agp0: Ali M1541 host to AGP bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci0: bridge, PCI-unknown at device 3.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xd800-0xd87f mem 0xdf00-0xdf7f irq 9 at device 9.0 on pci0 xl0: Ethernet
Re: SiI3112 SATA controller problems - status
It seems Will Andrews wrote: On Tue, Sep 30, 2003 at 10:06:40PM +0200, Soren Schmidt wrote: I have now found a way to reproduce the DMA problems some setups seems to be having with the SiI3112A SATA chip. Now, if I use real SATA drives, (and I mean real SATA drives, the WD Raptor fx is not a real SATA device but just a PATA device with a build in PATA-SATA converter chip) it works just fine no matter what I try. Interesting. SATA is also a power spec, right? I use a normal SATA cable but also an ATX power connector. I'm guessing that's what you mean by the Raptor not being a real SATA drive. No what I mean is that the Raptor is a PATA device fitted with a marvell PATA-SATA converter on board, its not a pure SATA design, but just the old stuff they used to make with the marvell chip kludged on the back :) The power connector is uninteresting in this context. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiI3112 SATA controller problems - status
On Tue, Sep 30, 2003 at 10:22:33PM +0200, Soren Schmidt wrote: No what I mean is that the Raptor is a PATA device fitted with a marvell PATA-SATA converter on board, its not a pure SATA design, but just the old stuff they used to make with the marvell chip kludged on the back :) The power connector is uninteresting in this context. Interesting, since no one's made any PATA drives that spin at 10,000 RPM as far as I know. For some reason I thought the interface change allowed for this (but couldn't come up with a good reason why it would make a difference). :) Thanks for your work, btw. Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiI3112 SATA controller problems - status
It seems Will Andrews wrote: On Tue, Sep 30, 2003 at 10:22:33PM +0200, Soren Schmidt wrote: No what I mean is that the Raptor is a PATA device fitted with a marvell PATA-SATA converter on board, its not a pure SATA design, but just the old stuff they used to make with the marvell chip kludged on the back :) The power connector is uninteresting in this context. Interesting, since no one's made any PATA drives that spin at 10,000 RPM as far as I know. For some reason I thought the interface change allowed for this (but couldn't come up with a good reason why it would make a difference). :) Hmm, PR? pricing? I guess its easier to make people shell out $$ for a pretty expensive 36G drive if you add SATA to the mix of features :) Thanks for your work, btw. I try :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with geom_bde
* Poul-Henning Kamp [EMAIL PROTECTED] [2003-09-30 10:54]: Did you call gbde detach before the umount ? You need to unmount first. After investigating further I think I have found the reason for the problem. When I created the disklabel for the partition I was lazy and entered a size of 200 blocks for the slice. I just tried to reproduce the problem and re-created the slice with a size of 1024M (which is 2097152 blocks) and the problem seems to have disappeared - at least I cannot reproduce it anymore. So now I wonder if there is any magic constant which the slice size needs to be a multiple of...? Regards -Thorsten -- There are 10 kinds of people in the world, those who understand binary and those who don't. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with geom_bde
In message [EMAIL PROTECTED], Thorsten Greiner writes: * Poul-Henning Kamp [EMAIL PROTECTED] [2003-09-30 10:54]: Did you call gbde detach before the umount ? You need to unmount first. After investigating further I think I have found the reason for the problem. When I created the disklabel for the partition I was lazy and entered a size of 200 blocks for the slice. I just tried to reproduce the problem and re-created the slice with a size of 1024M (which is 2097152 blocks) and the problem seems to have disappeared - at least I cannot reproduce it anymore. So now I wonder if there is any magic constant which the slice size needs to be a multiple of...? Not that I know off. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiI3112 SATA controller problems - status
Great news to hear Søren. Do you know when a snapshot with the fix will be available? Since I cannot complete a buildworld using the SATA drive without the fix. Thanks for the fix. -Derek At 10:06 PM 9/30/2003 +0200, Soren Schmidt wrote: I have now found a way to reproduce the DMA problems some setups seems to be having with the SiI3112A SATA chip. Now, if I use real SATA drives, (and I mean real SATA drives, the WD Raptor fx is not a real SATA device but just a PATA device with a build in PATA-SATA converter chip) it works just fine no matter what I try. If however I use an older PATA drive and a certain PATA-SATA dongle (in this case 1 out of 4 samples) I can reproduce the problem pretty easily. This suggests to me that we are looking at a timing problem of sorts the question is where. I'll work on the problem as time permits... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem w/ ACPI in -CURRENT: Update
I'm not sure what's causing these ACPI problems in this recent -CURRENT, but I've found where it's hanging. It's on this line: as = AcpiEvaluateObject(h, _BIF, NULL, bif_buffer); in acpi_cmbat.c in sys/dev/acpica/. The function AcpiEvaluateObject is found in contrib/dev/acpica/nsxfeval.c, which hasn't changed in a while. I tried adding a line to print out 'h', but I wasn't sure what to try to show it as. Prining it as an integer gave a weird negative value. What, exactly, should I be looking for here? -j -- /* You are not expected to understand this. */ Captain_Tenille http://www.satanosphere.com/ [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: TEST PLEASE: if_tun patch
On Sun, Sep 28, 2003 at 10:04:42PM -0700, Brooks Davis wrote: I'm not convinced this is the right direction to move in. The problem is that users are beginning to expect that pseudo-interfaces be created with network interface cloning, but tun, tap, and vmnet aren't. I'm Same about ef(4) pseudo-interfaces. Another thing is that someone may want to create vlan(4) and ef(4) pseudo-interfaces on tap(4) interface, like this: (1)ttyp4 [~]ifconfig tap19 tap19: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 10.19.0.1 netmask 0xff00 broadcast 10.19.0.255 inet6 fe80::2bd:69ff:fe94:13%tap19 prefixlen 64 scopeid 0x13 ether 00:bd:69:94:00:13 (2)ttyp4 [~]ifconfig vlan0 create (3)ttyp4 [~]ifconfig vlan0 vlan 123 vlandev tap0 (4)ttyp4 [~]ifconfig vlan0 vlan0: flags=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1496 ether 00:bd:68:94:00:00 vlan: 123 parent interface: tap0 (5)ttyp4 [~]kldload if_ef (6)ttyp4 [~]ifconfig tap19f2 tap19f2: flags=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether 00:bd:69:94:00:13 I have no idea if it works. ;) [screenshot from 4.x, I have no 5.x at this moment] It looks strange to have `ifconfig create' vlan interface on tap, while tap uses different semantics and can disappear after closing it? With ef it is even worse, pseudo-devices are created while ef is starting, so ef module must be loaded after creating every ethernet device. concerned that this destroy on last close semantic will make it harder to implement that. I guess if we moved to a model where we allowed both methods to work, we could somehow add an extra reference when we cloned interfaces via ifconfig if create, but I don't know the devfs side well enough to know if that's possible. -- Pawe Maachowski ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Improvements to fsck performance in -current ...?
Due to an electrician flipping the wrong circuit breaker this morning, I had my servers go down hard ... they are all -STABLE, with one of the four taking a *very* long time to fsck: jupiter# ps aux | grep fsck root 361 99.0 2.3 95572 95508 p0 R+4:21PM 121:13.21 fsck -y /dev/da0s1h jupiter# date Tue Sep 30 18:37:02 ADT 2003 jupiter# Now, CPU time is rising, so I figure its still working away, and fsck shows: jupiter# fsck -y /dev/da0s1h ** /dev/da0s1h ** Last Mounted on /vm ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts so it isn't finding any errors ... A friend of mine asked if we had a journalling file system, which I told him know, as I don't believe we do ... but are/have there been any improvements to fsck in -CURRENT to improve performance on large file systems (this is a 6x36G RAID5 system)? Does UFS2 address any of this? I've actually had a 6x18gig RAID5 file system once take 11+hrs to fsck ... and when it was completed, everything seemed fine, with no reports of any file or directory corruption ... it obviously did a good job of checking the file system, just hate the lengthy downtime ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem w/ ACPI in -CURRENT: Update
Please do not start new threads for the same problem as it makes it hard to track down what your problem even was originally. I assume your problem is hangs during boot, it appeared since 5.1R, and it goes away if you enable options INVARIANTS. Is that right? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem w/ ACPI in -CURRENT
On Tue, 23 Sep 2003, Jeremy Bingham wrote: On 23/09/03 18:07 -0700, Nate Lawson wrote: Enable options DDB. When it hangs, press CTRL-ALT-ESC and then tr to get a traceback. While ACPI influences this problem, I am uncertain it is the root cause. -Nate Way ahead of you there. I compiled a kernel with DDB on, installed it, and everything worked fine. No hangs or anything. When I recompiled the kernel with the debugging options off, the same hang happened again. Bizarre, to say the least. Again, booting with ACPI turned off worked fine. I'm making another debug kernel, and I'll try running that for a while. When you say debugging options, do you mean you added things other than options DDB (i.e. INVARIANTS or others)? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem w/ ACPI in -CURRENT: Update
On 30/09/03 14:48 -0700, Nate Lawson wrote: Please do not start new threads for the same problem as it makes it hard to track down what your problem even was originally. I assume your problem is hangs during boot, it appeared since 5.1R, and it goes away if you enable options INVARIANTS. Is that right? -Nate Yes, that is the case. It was only today that I managed to track down where the problem was cropping up, though. -j P.S. My apologies on the starting a new thread. -- /* You are not expected to understand this. */ Captain_Tenille http://www.satanosphere.com/ [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Problem w/ ACPI in -CURRENT: Update
On Tue, 30 Sep 2003, Jeremy Bingham wrote: On 30/09/03 14:48 -0700, Nate Lawson wrote: Please do not start new threads for the same problem as it makes it hard to track down what your problem even was originally. I assume your problem is hangs during boot, it appeared since 5.1R, and it goes away if you enable options INVARIANTS. Is that right? -Nate Yes, that is the case. It was only today that I managed to track down where the problem was cropping up, though. Are you sure you tracked it down to INVARIANTS? Or was it DDB? Please try with _just_ DDB and see if you can still reproduce the problem. If so, then when it hangs, hit CTRL-ALT-ESC and type tr. This will tell who is hung. As far as debugging prints, add the following printfs to acpi_cmbat_get_bif(): printf(Before getting BIF\n); as = AcpiEvaluateObject(h, _BIF, NULL, bif_buffer); printf(After getting BIF\n); -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
Date: Tue, 30 Sep 2003 18:42:21 -0300 (ADT) From: Marc G. Fournier [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Due to an electrician flipping the wrong circuit breaker this morning, I had my servers go down hard ... they are all -STABLE, with one of the four taking a *very* long time to fsck: jupiter# ps aux | grep fsck root 361 99.0 2.3 95572 95508 p0 R+4:21PM 121:13.21 fsck -y /dev/da0s1h jupiter# date Tue Sep 30 18:37:02 ADT 2003 jupiter# Now, CPU time is rising, so I figure its still working away, and fsck shows: jupiter# fsck -y /dev/da0s1h ** /dev/da0s1h ** Last Mounted on /vm ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts so it isn't finding any errors ... A friend of mine asked if we had a journalling file system, which I told him know, as I don't believe we do ... but are/have there been any improvements to fsck in -CURRENT to improve performance on large file systems (this is a 6x36G RAID5 system)? Does UFS2 address any of this? I've actually had a 6x18gig RAID5 file system once take 11+hrs to fsck ... and when it was completed, everything seemed fine, with no reports of any file or directory corruption ... it obviously did a good job of checking the file system, just hate the lengthy downtime ... Current has two major changes re speeding up fsck. The most significant is the background operation of fsck on file system with soft updates enabled. Because of the way softupdates works, you are assured of metadata consistency on reboot, so the file systems can be mounted and used immediately with fsck started up in the background about a minute after the system comes up. Until fsck runs it is possible (likely) that some free blocks on the filesystem amy be unavailable until the fsck completes, but that should be the only issue. The other issue is significant speedup in the time fsck takes to run. On my little 30 MB /usr/partition it now takes only seconds to fsck vs. about 2 minutes when I was running V4 on the system. On huge system, I suspect the speedup is even more significant, but don't know for sure. I suspect that these enhancements may both require that soft updates be enabled for the file systems. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TEST PLEASE: if_tun patch
On Tue, Sep 30, 2003 at 11:35:34PM +0200, Pawel Malachowski wrote: On Sun, Sep 28, 2003 at 10:04:42PM -0700, Brooks Davis wrote: I'm not convinced this is the right direction to move in. The problem is that users are beginning to expect that pseudo-interfaces be created with network interface cloning, but tun, tap, and vmnet aren't. I'm Same about ef(4) pseudo-interfaces. Another thing is that someone may want to create vlan(4) and ef(4) pseudo-interfaces on tap(4) interface, like this: (1)ttyp4 [~]ifconfig tap19 tap19: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 10.19.0.1 netmask 0xff00 broadcast 10.19.0.255 inet6 fe80::2bd:69ff:fe94:13%tap19 prefixlen 64 scopeid 0x13 ether 00:bd:69:94:00:13 (2)ttyp4 [~]ifconfig vlan0 create (3)ttyp4 [~]ifconfig vlan0 vlan 123 vlandev tap0 (4)ttyp4 [~]ifconfig vlan0 vlan0: flags=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1496 ether 00:bd:68:94:00:00 vlan: 123 parent interface: tap0 (5)ttyp4 [~]kldload if_ef (6)ttyp4 [~]ifconfig tap19f2 tap19f2: flags=8842BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether 00:bd:69:94:00:13 I have no idea if it works. ;) [screenshot from 4.x, I have no 5.x at this moment] It looks strange to have `ifconfig create' vlan interface on tap, while tap uses different semantics and can disappear after closing it? With ef it is even worse, pseudo-devices are created while ef is starting, so ef module must be loaded after creating every ethernet device. That's really evil. :-) The proper fix for the vanishing tap is probably some standard way for parents to know who their children are so they can hunt then down and notify them that they are being orphaned when they die. What the device would do it up to it since some devices like vlan and ef devices might as well die off, but an etherchannel device should just stop sending things to that interface. For ef, I'm thinking of expanding cloning so that we pass the requested name to each cloner for tasting and it decides if it can do that. Then vlans would be created and configured by doing something like: ifconfig fxp0.10 create and you could come up with a similar syntax for ef by appending f# to any ethernet's name to get the appropriate frame interface. A corrected form of the existing behavior could easily be implemented in userland by devd. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Improvements to fsck performance in -current ...?
On Tue, 30 Sep 2003, Kevin Oberman wrote: Current has two major changes re speeding up fsck. The most significant is the background operation of fsck on file system with soft updates enabled. Because of the way softupdates works, you are assured of metadata consistency on reboot, so the file systems can be mounted and used immediately with fsck started up in the background about a minute after the system comes up. Actually, I had this blow up on my -CURRENT desktop once ... didn't have a clue on how to debug it, so I switched from fsck -p to fsck -y to prevent it from happening again :( Now,I don't/wouldn't have softupdates enabled on / .. does the 'background fsck' know to not background if softupdates are not enabled? I'm going to switch back to -p and look a bit closer the next time it happens (if it happens) to see if it is/was a softupdate file system that failed, now that I have a better idea of what I'm looking for ... I suspect that these enhancements may both require that soft updates be enabled for the file systems. are either of these enhancements back-patchable to the 4.x fsck, or do they require some non-4.x compatible changes to work? ... I'm at 3.5hrs and counting right now ... any speedup would be great ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
On Tue, 30 Sep 2003, Marc G. Fournier wrote: Now,I don't/wouldn't have softupdates enabled on / .. does the 'background fsck' know to not background if softupdates are not enabled? Yes, this is no problem, if the FS doesn't have SU, it just checks it the old way. Since / is usually rather small, this is acceptable. I suspect that these enhancements may both require that soft updates be enabled for the file systems. are either of these enhancements back-patchable to the 4.x fsck, or do they require some non-4.x compatible changes to work? It's not just the fsck application itself, background fsck basically needs file system snapshots, which are only available on UFS2, and I'm not sure if they can be backported to UFS1 at all. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiI3112 SATA controller problems - status
On Sep 30, 2003, at 3:30 PM, Soren Schmidt wrote: It seems Will Andrews wrote: On Tue, Sep 30, 2003 at 10:22:33PM +0200, Soren Schmidt wrote: No what I mean is that the Raptor is a PATA device fitted with a marvell PATA-SATA converter on board, its not a pure SATA design, but just the old stuff they used to make with the marvell chip kludged on the back :) The power connector is uninteresting in this context. Interesting, since no one's made any PATA drives that spin at 10,000 RPM as far as I know. For some reason I thought the interface change allowed for this (but couldn't come up with a good reason why it would make a difference). :) Hmm, PR? pricing? I guess its easier to make people shell out $$ for a pretty expensive 36G drive if you add SATA to the mix of features :) Yeah... I feel somewhat betrayed. Time to switch to a different drive brand :) Thanks for your work, btw. I try :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
On Wed, Oct 01, 2003 at 01:04:51AM +0200, Lukas Ertl wrote: are either of these enhancements back-patchable to the 4.x fsck, or do they require some non-4.x compatible changes to work? It's not just the fsck application itself, background fsck basically needs file system snapshots, which are only available on UFS2, and I'm not sure if they can be backported to UFS1 at all. As soon as Kirk committed the snapshot capability, snapshot became available on UFS1. The only requirement is softupdates and softupdates pre-dates UFS2. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiI3112 SATA controller problems - status
On Tue, Sep 30, 2003 at 06:15:58PM -0500, David Leimbach wrote: Yeah... I feel somewhat betrayed. Time to switch to a different drive brand :) I should have bought a Maxtor 10K III U160 SCSI drive instead. :) Getting an appropriate controller would have been more expensive, but the drive's about the same... ;-\ Regards, -- wca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
On Wed, 1 Oct 2003, Lukas Ertl wrote: are either of these enhancements back-patchable to the 4.x fsck, or do they require some non-4.x compatible changes to work? It's not just the fsck application itself, background fsck basically needs file system snapshots, which are only available on UFS2, and I'm not sure if they can be backported to UFS1 at all. Ah, okay, so when I move my servers to 5.x, then I'm going to need to reformat the systems from scratch, else I lose some serious improvements ... is there a list somewhere of what UFS2 has over UFS1? file system snapshots, is that similar to journalling? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
On Tue, Sep 30, 2003 at 04:44:30PM -0700, Kevin Oberman wrote: Date: Tue, 30 Sep 2003 20:28:20 -0300 (ADT) From: Marc G. Fournier [EMAIL PROTECTED] On Wed, 1 Oct 2003, Lukas Ertl wrote: are either of these enhancements back-patchable to the 4.x fsck, or do they require some non-4.x compatible changes to work? It's not just the fsck application itself, background fsck basically needs file system snapshots, which are only available on UFS2, and I'm not sure if they can be backported to UFS1 at all. Ah, okay, so when I move my servers to 5.x, then I'm going to need to reformat the systems from scratch, else I lose some serious improvements ... is there a list somewhere of what UFS2 has over UFS1? file system snapshots, is that similar to journalling? I think this is wrong. I have seen no issue in snapshots or background fsck with UFS1 volumes. And, if you mean jounalling as in jfs, no. As I understand it, snapshot is an atomic capture of the file system metadata which allows fsck to analyze and repair it on an active file system. (Note: This only applies to softupdate enabled systems as softupdates assure a level of consistency in the metadata that assures that fsck will not make changes to active file space on the file system. To get to UFS2, you must newfs the partition. I don't know of nay other way. The basic improvement in UFS2 is the expansion of many fields to 64 bits to allow for much larger structures. While newfs in V5.1 and CURRENT defaults to UFS2, there are no problems continuing to run UFS1 file systems. UFS2 also allocates less inodes at newfs time and instead adds them on demand so you have less of them to check when you don't have any files using them. Finally, I don't think there is any issue any longer with using soft updates on /. The only reason that root did not default to SU under V4 is that SU disks only periodically update free space information and a small root partition can fill up during an installworld when all of the files in (especially) /sbin are replaces which requires enough space to hold two copies of the directory. Under the default partition sizes in V5, this is really not an issue and all partitions created by sysinstall under V5 will default to SU, including /. I believe this problem has been fixed. At least that's what I got out of Kirk's talk as BSDCon. If you have a USENIX membership, you can read about UFS2 at: http://www.usenix.org/publications/library/proceedings/bsdcon03/tech/mckusick.html -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Improvements to fsck performance in -current ...?
Lukas Ertl [EMAIL PROTECTED] wrote: It's not just the fsck application itself, background fsck basically needs file system snapshots, which are only available on UFS2, and I'm not sure if they can be backported to UFS1 at all. Huh? Snapshots are available for both UFS1 and UFS2, but only on 5.x. -- Christian naddy Weisgerber [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
umass(4)/uhci(4) REALLY slow
Here are iostat 5 results for my USB thumb drive on a uhci(4) controller with 5.1-CURRENT. On windows on the same box, it runs reasonably quickly. On FreeBSD, it really lags. This is for a cp of a large file to a msdosfs-mounted flash drive. da0 KB/t tps MB/s 1.07 41 0.04 1.00 41 0.04 1.02 41 0.04 Is there something we're doing on uhci(4) that makes each transfer only 1 KB? If we upped it to 32 KB, it would be a more reasonable 1.2 MB/sec which is still well under the USB 1.1 max speed. Thanks, -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Improvements to fsck performance in -current ...?
On Tue, 30 Sep 2003, Marc G. Fournier wrote: Current has two major changes re speeding up fsck. The most significant is the background operation of fsck on file system with soft updates enabled. Because of the way softupdates works, you are assured of metadata consistency on reboot, so the file systems can be mounted and used immediately with fsck started up in the background about a minute after the system comes up. Actually, I had this blow up on my -CURRENT desktop once ... didn't have a clue on how to debug it, so I switched from fsck -p to fsck -y to prevent it from happening again :( No idea when this happened to you, but background fsck/snapshots have become dramatically more stable since about half way between 5.0-release and 5.1-release. Kirk chased down a lot of serious bugs and issues with hangs. So experience from before that time may not be characteristic of current behavior. Now,I don't/wouldn't have softupdates enabled on / .. does the 'background fsck' know to not background if softupdates are not enabled? I'm going to switch back to -p and look a bit closer the next time it happens (if it happens) to see if it is/was a softupdate file system that failed, now that I have a better idea of what I'm looking for ... sysinstall doesn't enable soft updates on / by default, as for small partitions you increase the chance of running into space concerns. Many of the space concerns have been resolved by some more recent behavioral changes in UFS. The issue in question is that soft updates trickles out changes in a write-behind, and in the event of a large delete followed by an immediate large allocation, the deleted storage may not have been reclaimed when the allocation comes along. For example, if you had a really small / and did an installkernel. In more recent 5.x, UFS now tracks the space that will be freed and reports it as freed, and includes some support for waiting for space to become available (which it inevitably will in that situation, once the soft updates have been processed). So the picture may have improved a lot since you last used it, depending on when that was. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: Change of makedev() semantics.
On Sun, 28 Sep 2003, Poul-Henning Kamp wrote: Basically: 1. Do not call makedev(). 2. If you do cloning, please look at the patches I posted for if_tun/if_tap for how to do it. show an actual document please, explaining how this works from the user's POV.. 3. If you do a normal device driver, cache the result from when you call make_dev(). 4. If you translate foreign dev_t's, ie emulators or compat code, contact me. I'm not sure I understand how this works and should work and we need to talk. 5. If anything else or in doubt, ask me. more docs on how you invisage clonign to work. Can I see some volounteers and/or maintainers please ? ./dev/nmdm/nmdm.c pseudo-cloning. Should do real cloning. If the documentation is easily available and it does what I want I'll convert it.. It may be available but I haven't seen it.. man make_dev(9) doesn't have any 'see also' section that helps.. So, why should I not revoke a vnode that now refers to nothing? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serial debug broken in recent -CURRENT?
On Tuesday, 30 September 2003 at 16:13:09 -0400, Andrew Gallatin wrote: Sam Leffler writes: It reliably locks up for me when you break into a running system; set a breakpoint; and then continue. Machine is UP+HTT. Haven't tried other machines. Perhaps related, perhaps a red-herring: With a single P4 + HTT, + SMP kernel, if I break into the ddb debugger on a serial console, the machine locks solid about 1 in 4 times. Hmm, the first suggestion that it's possibly transient. My machine is a 2 processor Celeron 500 (obviously not HTT :-). I get the same results when debugging over firewire, which suggest that the problem isn't in the serial link handling. Greg -- See complete headers for address and phone numbers. NOTE: Due to the currently active Microsoft-based worms, I am limiting all incoming mail to 131,072 bytes. This is enough for normal mail, but not for large attachments. Please send these as URLs. pgp0.pgp Description: PGP signature
Re: Problems with geom_bde
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : So now I wonder if there is any magic constant which the slice size : needs to be a multiple of...? : : Not that I know off. Actually, there is, but it isn't constant. slices need to be an even number of 'cylendars' in the fdisk label. Some BIOSes use this to determine the geometry of the disk. Some BIOSes have issues booting when these numbers are correct. By making the the partition size different, the BIOS was able to properly grok things and booting worked. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
getdirtybuf: interlock not locked but should be
I'm working on getting the AFS client to work under FreeBSD. I just compiled a -current kernel with DEBUG_VFS_LOCKS, and before I could even load the AFS module I had the system stop with the following locking assertion: getdirtybuf: 0xc2678000 interlock is not locked but should be Backtrace looks like: getdirtybuf(de17cbb4, 0, 1, c7732ba0, 1) +0xee flush_deplist(c268ad4c, 1, de17cbdc, de17cbe0, 0) +0x43 flush_inodedep_deps(c267,1ab,,c26ed000,124) +0xa3 softdep_sync_metadata(de17cca4, 0, c037b672, 124, 0) +0x87 ffs_fsync(de17cca4, c03714ea, c0373416, ad8, 0) +0x3b9 fsync(c25d7850, de17cd10, c038276b, 3ec, 1) +0x1d4 syscall() ... One vnode is locked: 0xc26ed000: tag ufs, type VREG, usecount 1, writecount 1, refcount 1, flags (VV_OBJBUF), lock type ufs: EXCL (count 1) by thread 0xc25d7850 ino 427, on dev ad0s1a (4, 13) This is repeated four times with the same vnode. Obviously, it would help to have a solution to this problem so that I can debug what I'm really interested in rather than worrying about UFS. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umass(4)/uhci(4) REALLY slow
On Tue, 30 Sep 2003, Nate Lawson wrote: Here are iostat 5 results for my USB thumb drive on a uhci(4) controller with 5.1-CURRENT. On windows on the same box, it runs reasonably quickly. On FreeBSD, it really lags. This is for a cp of a large file to a msdosfs-mounted flash drive. da0 KB/t tps MB/s 1.07 41 0.04 1.00 41 0.04 1.02 41 0.04 Is there something we're doing on uhci(4) that makes each transfer only 1 KB? If we upped it to 32 KB, it would be a more reasonable 1.2 MB/sec which is still well under the USB 1.1 max speed. This is probably due to something we're not doing in msdosfs. 1K is probably your msdosfs file system block size. msdosfs is missing support for clustering. None of the lower levels (buffer cache, driver, usb) in FreeBSD does clustering (the buffer cache has some support for it, but this is mostly turned off because the file system doesn't ask for it). The lower levels not in FreeBSD (firmware and hardware) apparently don't do clustering either. This results in abysmal performance if the msdosfs block size is small. It would be twice as abysmal with the minimum block size of 512. Similarly for ffs with small block sizes and lots of fragments if write clustering is turned off if the drive doesn't do it. My early model SCSI ZIP100 drive gave similar performance (command overhead of about 25 msec = 40 tps). My not so early model ATA ZIP100 drive now does 230 tps; its tps is almost independent of the block size for block sizes = 4K, so its performance is reduced by a factor of only up to 8 by using small block sizes. The buffer cache also handles small block sizes poorly. If nbuf is 2048, then a whole 1MB of data can be in the buffer cache for a file system with a block size of 512. Using such a file system will soon (*) use most buffers for tinygrams and deplete the buffer cache for other file systems. However, disks will normally stay cached in VMIO buffers, so this only thrashes the disk caches in memory, so it is now worse than copying all the data several times per access. (*) Only RSN with 41 tps :-). Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
