Re: 40% slowdown with dynamic /bin/sh
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Andrew Gallatin <[EMAIL PROTECTED]> writes: : I'll bet a larger percentage of our users build ports than need nss or : ldap. I'll bet a larger percentage of the people are ignoring this thread than reading it since it has been so devoid of concrete numbers. Amen! More benchmarks, less speculation, please. Since both variants are already implemented, any argument lacking measurements is weak. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
anoncvs connection refused?
Hi, I've seen this for the last few days: [EMAIL PROTECTED]: /usr/src] make -DCVS_UPDATE update -- >>> Updating /usr/src from cvs repository -- cd /usr/src; cvs -R -q update -A -P -d cvs [update aborted]: connect to anoncvs.freebsd.org(209.181.243.20):2401 failed: Connection refused *** Error code 1 Is anoncvs filtering me? Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ATAng regression: cdcontrol close not working
Soren Schmidt wrote: FYI, this is still an issue: s = ioctl(fd, CDIOCCLOSE, 0) IOError: [Errno 16] Device busy Hmm, if the call to do the close fails there isn't much I can do... I can't reproduce the problem on any of the dozens of ATAPI CDROM's I have in the closet, so if you want to get further with this, you'll have to instrument the code and find out exactly why this fails. Maybe then I can find a solution that can work, and not break anything. I'll see what I can find out. It probably doesn't help you to know that the same hardware worked fine with the old ATA code... Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ATAng regression: cdcontrol close not working
Lars Eggert wrote: Soren Schmidt wrote: Is there any other patch I can try? I've just confirmed that this bug still exists with today's kernel. I cant reproduce the no matter what I try, sorry... Would remote access to the machine in question help you? FYI, this is still an issue: s = ioctl(fd, CDIOCCLOSE, 0) IOError: [Errno 16] Device busy Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: NFSv4 Client code committed.
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Andrzej Tobola <[EMAIL PROTECTED]> writes: : Did you tested it with nfsclient dynamically loaded ? I can't load nfs4client.ko either. If you put all the files/paths in nfsclient, it will load and work. I load nfsclient.ko in my boot loader, so I couldn't boot at all due to the unresolved symbols. :-( Warner P.S. Here's what I have in p4 to make it work. FYI, your Makefile fixes things for me, too. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ifconfig bug
Bruce M Simpson wrote: On Sat, Nov 15, 2003 at 11:54:20AM -0800, Lars Eggert wrote: shouldn't this work? # ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \ ether 00:07:e9:0a:26:52 ifconfig: ether: bad value This is with today's -current, but this may have been around longer - I hadn't tried it before today. Using two commands to set MAC and IP addresses works fine, but it needs to be one command for rc.conf. This issue is already known about and the behaviour you are seeing is in accordance with how ifconfig should currently behave. I suggest patching rc scripts until it can be solved the right way round. Thanks for the explanations! I'll work around this with a start_if.em0 script then. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
ifconfig bug
Hi, shouldn't this work? # ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \ ether 00:07:e9:0a:26:52 ifconfig: ether: bad value This is with today's -current, but this may have been around longer - I hadn't tried it before today. Using two commands to set MAC and IP addresses works fine, but it needs to be one command for rc.conf. Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: NFSv4 Client code committed.
Andrzej Tobola wrote: Just cvsuped. kldload nfsclient is now not working: link_elf: symbol nfs4_writebp undefined Did you tested it with nfsclient dynamically loaded ? Same here. Is there a way to fall back to the old code? Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: New interrupt code slows hyperthreading down
John Baldwin wrote: On 07-Nov-2003 Lars Eggert wrote: Jens Rehsack wrote: interrupt total rate irq1: atkbd0 512 2 irq8: rtc 23419127 irq13: npx01 0 irq14: ata0 4422 24 irq15: ata1 82 0 irq16: uhci0 uhci3 5379815 29238 This looks similar to what I described in the "fwohci0 running wild" thread. In both cases, irq16 seems to cause the problem... Really. Does this only happen with ACPI enabled? Don't know about "only", since I have never booted this machine without ACPI. I'll test next time I'm rebooting. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: New interrupt code slows hyperthreading down
Jens Rehsack wrote: interrupt total rate irq1: atkbd0 512 2 irq8: rtc 23419127 irq13: npx01 0 irq14: ata0 4422 24 irq15: ata1 82 0 irq16: uhci0 uhci3 5379815 29238 This looks similar to what I described in the "fwohci0 running wild" thread. In both cases, irq16 seems to cause the problem... Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: PRs for dagrab and cdparanoia reworked
Simon Barner wrote: FWIW, the mplayer port also cannot play CDDA anymore on current. It probably needs a similar patch. This works for me with a patched version of cdparanoia, which makes sense, since mplayer is linked against libcdda_paranoia.so.0. You can get the patch here: http://home.leo.org/~barner/freebsd/cdparanoia-pread.patch Great. I had not tracked the issue closely enough to find the dependency on cdparanoia. Everything will be fine then once that patch is in the ports tree. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: new interrupt code? fwohci0 running wild
John Baldwin wrote: What happens if you kldunload the firewire driver? Also, what happens if you boot w/o it loaded in the first place? kldunload does not make a difference, it still eats irqs. Not loading it in the first place works around the issue, and returns the machine's responsiveness back to normal. It's the workaround I'm using for now. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
sysinstall issues (was Re: Toshiba Portege R100: 5.1-JPSNAP install CD hangs)
Takayama Fumihiko wrote: booting a Toshiba Portege R100 off Wednesday's 5.1-JPSNAP install CD hangs early during the boot, with or without ACPI. It may be related to probing the graphics chip, see the attached snapshot. I've also attached the 4.9 dmesg - 4.9 boots fine off its install CD - in case that helps. Any ideas? R100 has problem with PnP for FreeBSD. My Toshiba Portege R100 on FreeBSD 5.1-RELEASE can boot by below process. 1) enter BIOS setup (booting with press ESC) 2) [Device Config] change to "All Devices" from "Setup by OS" Thank you very much, Fumihiko-san, that solved the booting problem! However, I was still unable to install 5.1-JPSNAP on the machine. With the BIOS settings you suggested, I managed to get to sysinstall. After specifying the desired install setting, sysinstall refuses to install, claiming it did not detect a CD/DVD drive? The drive in question is detected during boot as: umass0: NewAge International STORIX Optical Series, rev 2.00/0.01 (see http://www.isi.edu/larse/misc/DSC00909.JPG) Can sysinstall not install off of USB drives? To circumvent this issue, I copied the install CD contents onto a local FTP server, and tried a network install. After contacting the server and formatting the partition, sysinstall panic'ed died with an ffs panic. A snapshot of the traceback is here: http://www.isi.edu/larse/misc/DSC00908.JPG Any ideas on how to pull -current onto this laptop, other then installing -stable and compiling from scratch? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ATAng regression: cdcontrol close not working
Soren Schmidt wrote: Is there any other patch I can try? I've just confirmed that this bug still exists with today's kernel. I cant reproduce the no matter what I try, sorry... Would remote access to the machine in question help you? Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ATAng regression: cdcontrol close not working
Bruce Evans wrote: On Thu, 30 Oct 2003, Soren Schmidt wrote: Anyhow if you loose the test for error in atapi-cd.c::acd_tray in the close case, does it work then ? Problem is that the call to read toc might fail early, but its worth a shot.. I tried this, but it didn't change anything. (See my mail from last week.) I was mistaken in thinking that my patch fixed this. It only works for 1 drive, as does at acd^H^Htapi-cd.c rev.1.148. Is there any other patch I can try? I've just confirmed that this bug still exists with today's kernel. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
new interrupt code? fwohci0 running wild
Hi, just made and installed today's world, and while the system boots, performance is sluggish. This is likely due to irq16/fwohci0, which seems to run wild: [EMAIL PROTECTED]: /] uptime && vmstat -i 11:21AM up 9 mins, 3 users, load averages: 0.54, 0.71, 0.43 interrupt total rate irq6: fdc0 4 0 irq8: rtc 72244127 irq13: npx01 0 irq14: ata0 1868 3 irq15: ata1 97 0 irq16: fwohci0 50191801 88835 irq17: em1 24890 44 irq18: pcm0 25 0 irq19: uhci0 bktr0 4551 8 irq20: mpt0 46 0 irq21: em0 mpt1 8003 14 irq0: clk 56443 99 Total 50359973 89132 Nothing is plugged into the firewire port, if that matters. The machine is an SMP box, dmesg and pciconf output are attached. Please let me know what other information I can provide. Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute [EMAIL PROTECTED]:0:0: class=0x06 card=0x00d81028 chip=0x25318086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82860 (860) CPU to I/O Hub Bridge (Interface A)' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x25328086 rev=0x04 hdr=0x01 vendor = 'Intel Corporation' device = '82850/850E/860 AGP Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:2:0: class=0x060400 card=0x chip=0x25338086 rev=0x04 hdr=0x01 vendor = 'Intel Corporation' device = '82860 (860) PCI Bridge (Hub Interface B)' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:30:0: class=0x060400 card=0x chip=0x244e8086 rev=0x04 hdr=0x01 vendor = 'Intel Corporation' device = '82801BA/CA/DB/EB/ER (ICH2/3/4/5/5R) Hub Interface to PCI Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:31:0: class=0x060100 card=0x chip=0x24408086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA (ICH2) LPC Interface Controller' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:31:1: class=0x010180 card=0x00d81028 chip=0x244b8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA (ICH2) UltraATA/100 IDE Controller' class= mass storage subclass = ATA [EMAIL PROTECTED]:31:2: class=0x0c0300 card=0x00d81028 chip=0x24428086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) USB Universal Host Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:31:3: class=0x0c0500 card=0x00d81028 chip=0x24438086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) SMBus Controller' class= serial bus subclass = SMBus [EMAIL PROTECTED]:31:4: class=0x0c0300 card=0x00d81028 chip=0x24448086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801BA/BAM (ICH2/ICH2-M) USB Universal Host Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:0:0: class=0x03 card=0x7176174b chip=0x49661002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies' device = 'RV250 Radeon 9000/9000 Pro' class= display subclass = VGA [EMAIL PROTECTED]:0:1: class=0x038000 card=0x7177174b chip=0x496e1002 rev=0x01 hdr=0x00 vendor = 'ATI Technologies' device = 'RV250 Radeon 9000/9000 Pro - Secondary' class= display [EMAIL PROTECTED]:31:0: class=0x060400 card=0x chip=0x13608086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82806AA Hub Interface to PCI Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:0:0: class=0x080020 card=0x11618086 chip=0x11618086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82806AA PCI64 Hub Advanced Programmable Interrupt Controller' class= base peripheral subclass = interrupt controller [EMAIL PROTECTED]:12:0: class=0x01 card=0x10401028 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class= mass storage subclass = SCSI [EMAIL PROTECTED]:12:1: class=0x01 card=0x10401028 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)
Re: PRs for dagrab and cdparanoia reworked
Simon Barner wrote: please revise the patch and submit follow-up. Done. Tested on both -STABLE and -CURRENT. I am progress of doing the same for dagrab (expect a follow-up to PR 57227 soon). FWIW, the mplayer port also cannot play CDDA anymore on current. It probably needs a similar patch. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Toshiba Portege R100: 5.1-JPSNAP install CD hangs
Lars Eggert wrote: hangs early during the boot, with or without ACPI. It may be related to probing the graphics chip, see the attached snapshot. Seems to have been stripped off, find it here: http://www.isi.edu/larse/misc/5.1-brief.jpg Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Toshiba Portege R100: 5.1-JPSNAP install CD hangs
Hi, booting a Toshiba Portege R100 off Wednesday's 5.1-JPSNAP install CD hangs early during the boot, with or without ACPI. It may be related to probing the graphics chip, see the attached snapshot. I've also attached the 4.9 dmesg - 4.9 boots fine off its install CD - in case that helps. Any ideas? Thanks, Lars PS: Sorry for posting an image - the laptop has no serial port. -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.9-RELEASE #0: Mon Oct 27 17:51:09 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz CPU: Intel(R) Pentium(R) M processor 1000MHz (997.50-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf real memory = 805085184 (786216K bytes) avail memory = 777445376 (759224K bytes) Preloaded elf kernel "kernel" at 0xc053f000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 7 entries at 0xc00f0200 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 agp0: mem 0xc000-0xcfff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at 0.0 irq 11 uhci0: port 0xefe0-0xefff irq 11 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xef80-0xef9f irq 11 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: at 29.7 pcib2: at device 30.0 on pci0 pci2: on pcib2 fxp0: port 0xcf40-0xcf7f mem 0xdfdff000-0xdfdf irq 11 at device 8.0 on pci2 fxp0: Ethernet address 00:08:0d:3b:4c:17 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: (vendor=0x8086, dev=0x1043) at 10.0 irq 11 pci_cfgintr_linked: linked (60) to hard-routed irq 11 pci_cfgintr: 2:11 INTA routed to irq 11 pcic0: irq 11 at device 11.0 on pci2 pcic0: PCI Memory allocated: 0x8800 pccard0: on pcic0 pci2: (vendor=0x1179, dev=0x0805) at 13.0 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xbfa0-0xbfaf,0xbfe4-0xbfe7,0xbfe8-0xbfef,0xbff4-0xbff7,0xbff8-0xbfff irq 11 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: (vendor=0x8086, dev=0x24c5) at 31.5 pci0: (vendor=0x8086, dev=0x24c6) at 31.6 orm0: at iomem 0xc-0xcbfff,0xe-0xe on isa0 pmtimer0 on isa0 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 sio1: configured irq 3 not in bitmap of probed irqs 0 ppc0: parallel port not found. ad0: 38147MB [77506/16/63] at ata0-master BIOSDMA Mounting root from ufs:/dev/ad0s2a smime.p7s Description: S/MIME Cryptographic Signature
Re: wi problem with message > 7400 bytes
Daniel Eischen wrote: Could you post a tcpdump for each case? I wonder if this is related to a fragmentation issue I've seen in the past. 22:46:43.513038 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52198:[EMAIL PROTECTED]) 22:46:48.522475 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52199:[EMAIL PROTECTED]) 22:46:53.532018 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52200:[EMAIL PROTECTED]) 22:46:58.541178 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52201:[EMAIL PROTECTED]) 22:47:03.553048 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52202:[EMAIL PROTECTED]) 22:47:08.568862 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52203:[EMAIL PROTECTED]) 22:47:13.583328 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52204:[EMAIL PROTECTED]) 22:47:18.578512 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52205:[EMAIL PROTECTED]) 22:47:23.609098 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52206:[EMAIL PROTECTED]) 22:47:28.597680 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52207:[EMAIL PROTECTED]) 22:47:33.607059 gpz.foo.bar.com.38340 > vespa.12345: udp 7393 (frag 52208:[EMAIL PROTECTED]) It's not what I've seen in the past - but also pretty strange! Only the first fragment seems to be received. Wonder what happened to the other fragments... If you tcpdump on gpz, does the output look the same? Also, you may want to run the tcpdump without a filter (if you don't do this already) to see if the other fragments show up as corrputed frames or something. (As an aside, fragmentation on a lossy link compounds throughput issues, but of course you know that already.) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: wi problem with message > 7400 bytes
Daniel Eischen wrote: Greetings, I'm having a problem receiving UDP messages over a wi interface: wi1: at port 0x180-0x1bf irq 11 function 0 config 1 on pccard0 wi1: 802.11 address: 00:02:2d:4a:d8:7d wi1: using Lucent Technologies, WaveLAN/IEEE wi1: Lucent Firmware: Station (6.10.1) wi1: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps (wi0 is also a 'Dell TrueMobile 1150 Series PC Card' in a mini-PCI card, but hangs the system when you try and configure it -- so it obviously isn't configured in this set up.) I have a small program that does a trivial UDP test: http://people.freebsd.org/~deischen/udptest.c My results show that: o Receiving large (> 7400 bytes) messages does not work. o Sending large messages works. o Sending & receiving large messages over a wired interface (dc, fxp, etc) works. Am I suppose to be able to receive UDP messages larger than 7400 bytes over the air? Could you post a tcpdump for each case? I wonder if this is related to a fragmentation issue I've seen in the past. Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ATAng regression: cdcontrol close not working
Soren Schmidt wrote: Anyhow if you loose the test for error in atapi-cd.c::acd_tray in the close case, does it work then ? If you mean as below, no, that didn't help: Index: atapi-cd.c === RCS file: /home/ncvs/src/sys/dev/ata/atapi-cd.c,v retrieving revision 1.149 diff -u -r1.149 atapi-cd.c --- atapi-cd.c 18 Oct 2003 17:24:51 - 1.149 +++ atapi-cd.c 30 Oct 2003 21:31:23 - @@ -1884,11 +1884,10 @@ if (cdp->cap.mechanism & MST_EJECT) { if (close) { - if (!(error = acd_start_stop(cdp, 3))) { - acd_read_toc(cdp); - acd_prevent_allow(cdp, 1); - cdp->flags |= F_LOCKED; - } +error = acd_start_stop(cdp, 3); + acd_read_toc(cdp); + acd_prevent_allow(cdp, 1); + cdp->flags |= F_LOCKED; } else { acd_start_stop(cdp, 0); Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ATAng regression: cdcontrol close not working
Soren Schmidt wrote: It seems Lars Eggert wrote: FYI, the issue is still present with yesterday's -current. Will Pav Lucistnik's patch be committed soon? I've already committed a solution that works on all the drives I could test on (some of which failed before), if this still fails for you I'd like a more detailed description of what exactly goes wrong... I must have missed that commit message, sorry. This is the drive I am having the issues with: acd0: CDRW at ata1-master UDMA33 I also have atapicam in the kernel: cd0: Removable CD-ROM SCSI-0 device I have the same issue as the original poster: "cdcontrol -f /dev/acd0 eject" -> ejects tray "cdcontrol -f /dev/acd0 close" -> does nothing "cdcontrol -f /dev/cd0 eject" -> ejects tray "cdcontrol -f /dev/cd0 close" -> retracts tray cdcontrol does not show any messages, even with -v. Sending CDIOCCLOSE from a short C snippet shows that the ioctl yields EBUSY. (I also tried to get a ktrace, but that just shows "Events dropped" where the trace becomes interesting. Issue with -current?) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ATAng regression: cdcontrol close not working
Soren Schmidt wrote: It seems Pav Lucistnik wrote: This patch works for me. Any chance to get it committed? I'll look at it... FYI, the issue is still present with yesterday's -current. Will Pav Lucistnik's patch be committed soon? Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ENE 4-in-1 card reader
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Lars Eggert <[EMAIL PROTECTED]> writes: : we've got an Asus Pundit here that has an onboard 4-in-1 memory card reader: : : [EMAIL PROTECTED]:16:1:class=0x050100 card=0x17241043 chip=0x05101524 : rev=0x00 : hdr=0x00 : vendor = 'ENE Technology Inc' : class= memory : subclass = flash : : Is there a driver for this under -current yet? What's at device 16.0? [EMAIL PROTECTED]:16:0: class=0x060700 card=0x14111524 chip=0x14111524 rev=0x01 hdr=0x02 vendor = 'ENE Technology Inc' class= bridge subclass = PCI-CardBus Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
include/xmmintrin.h
Hi, include/xmmintrin.h defines __v4si twice, once in line 45, and once again in line 1113 inside an __SSE2__ ifdef block. This causes errors when building ports that define __SSE2__. I locally fixed this by removing the second definition of __v4si. Not sure what the right solution is, because xmmintrin.h is contributed code from gcc. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: NFS corruption on p4 machines (please test)
Kris Kennaway wrote: On Fri, Oct 03, 2003 at 10:10:20AM -0700, Lars Eggert wrote: Kris, Kris Kennaway wrote: For some months now I have been experiencing NFS corruption on the three machines in the dosirak.kr package cluster - these are SMP pentium 4 machines that run -CURRENT. Setting DISABLE_PSE and DISABLE_PG_G does not fix these problems. I am able to easily reproduce these problems using /usr/src/tools/regression/fsx on a loopback nfs mount - they are not deterministic, but it blows up within about 8000 operations (less than a minute of operation). In fact sometimes it even manages to make fsx segfault, which is fairly impressive :) Just mount something rw via loopback nfs, and run 'fsx foo' on the nfs filesystem for a few minutes. I just ran an fsx cycle on my desktop machine over a TCP mount, and it seemed to work fine: Thanks. What hardware specs? Attached. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute cam: using minimum scsi_delay (100ms) Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #0: Tue Sep 30 10:11:59 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KERNEL-1.31 Preloaded elf kernel "/boot/kernel/kernel" at 0xc06ed000. Preloaded elf module "/boot/kernel/vesa.ko" at 0xc06ed21c. Preloaded elf module "/boot/kernel/md.ko" at 0xc06ed2c8. Preloaded elf module "/boot/kernel/linux.ko" at 0xc06ed370. Preloaded elf module "/boot/kernel/if_gif.ko" at 0xc06ed41c. Preloaded elf module "/boot/kernel/if_tun.ko" at 0xc06ed4c8. Preloaded elf module "/boot/kernel/ipfw.ko" at 0xc06ed574. Preloaded elf module "/boot/kernel/if_an.ko" at 0xc06ed620. Preloaded elf module "/boot/kernel/wlan.ko" at 0xc06ed6cc. Preloaded elf module "/boot/kernel/rc4.ko" at 0xc06ed778. Preloaded elf module "/boot/kernel/pccard.ko" at 0xc06ed820. Preloaded elf module "/boot/kernel/if_em.ko" at 0xc06ed8cc. Preloaded elf module "/boot/kernel/if_fxp.ko" at 0xc06ed978. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc06eda24. Preloaded elf module "/boot/kernel/if_lnc.ko" at 0xc06edad0. Preloaded elf module "/boot/kernel/if_wi.ko" at 0xc06edb7c. Preloaded elf module "/boot/kernel/if_xl.ko" at 0xc06edc28. Preloaded elf module "/boot/kernel/snd_emu10k1.ko" at 0xc06edcd4. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc06edd84. Preloaded elf module "/boot/kernel/snd_es137x.ko" at 0xc06ede30. Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc06edee0. Preloaded elf module "/boot/kernel/snd_maestro3.ko" at 0xc06edf8c. Preloaded elf module "/boot/kernel/ugen.ko" at 0xc06ee040. Preloaded elf module "/boot/kernel/usb.ko" at 0xc06ee0ec. Preloaded elf module "/boot/kernel/uhid.ko" at 0xc06ee194. Preloaded elf module "/boot/kernel/ukbd.ko" at 0xc06ee240. Preloaded elf module "/boot/kernel/ulpt.ko" at 0xc06ee2ec. Preloaded elf module "/boot/kernel/ums.ko" at 0xc06ee398. Preloaded elf module "/boot/kernel/umass.ko" at 0xc06ee440. Preloaded elf module "/boot/kernel/umodem.ko" at 0xc06ee4ec. Preloaded elf module "/boot/kernel/ucom.ko" at 0xc06ee598. Preloaded elf module "/boot/kernel/bktr.ko" at 0xc06ee644. Preloaded elf module "/boot/kernel/bktr_mem.ko" at 0xc06ee6f0. Preloaded elf module "/boot/kernel/agp.ko" at 0xc06ee7a0. Preloaded elf module "/boot/kernel/random.ko" at 0xc06ee848. Preloaded elf module "/boot/kernel/ip_mroute.ko" at 0xc06ee8f4. Preloaded elf module "/boot/kernel/ip6fw.ko" at 0xc06ee9a4. Preloaded elf module "/boot/kernel/netgraph.ko" at 0xc06eea50. Preloaded elf module "/boot/kernel/dummynet.ko" at 0xc06eeb00. Preloaded elf module "/boot/kernel/radeon.ko" at 0xc06eebb0. Preloaded elf module "/boot/kernel/r128.ko" at 0xc06eec5c. Preloaded elf module "/boot/kernel/ahc.ko" at 0xc06eed08. Preloaded elf module "/boot/kernel/mpt.ko" at 0xc06eedb0. Preloaded elf module "/boot/kernel/fdc.ko" at 0xc06eee58. Preloaded elf module "/boot/kernel/cbb.ko" at 0xc06eef00. Preloaded elf module "/boot/kernel/exca.ko" at 0xc06eefa8. Preloaded elf module "/boot/kernel/cardbus.ko" at 0xc06ef054. Preloaded elf module "/boot/kernel/lpt.ko" at 0xc06ef100. Preloaded elf module "/boot/kernel/ubsa.ko" at 0xc06ef1a8. Preloaded elf module "/boot/kernel/firewire.ko" at 0xc06ef254. Preloaded elf module "/boot/kernel/sbp.ko" at 0xc06ef304. Preloaded elf module "/boot/kernel/smbus.ko" at 0xc06ef3ac. Pr
Re: NFS corruption on p4 machines (please test)
Lars Eggert wrote: Kris Kennaway wrote: Just mount something rw via loopback nfs, and run 'fsx foo' on the nfs filesystem for a few minutes. I just ran an fsx cycle on my desktop machine over a TCP mount, and it seemed to work fine: I should have mentioned that this is a Pentium 4 Xeon SMP machine running -current. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: NFS corruption on p4 machines (please test)
Kris, Kris Kennaway wrote: For some months now I have been experiencing NFS corruption on the three machines in the dosirak.kr package cluster - these are SMP pentium 4 machines that run -CURRENT. Setting DISABLE_PSE and DISABLE_PG_G does not fix these problems. I am able to easily reproduce these problems using /usr/src/tools/regression/fsx on a loopback nfs mount - they are not deterministic, but it blows up within about 8000 operations (less than a minute of operation). In fact sometimes it even manages to make fsx segfault, which is fairly impressive :) Just mount something rw via loopback nfs, and run 'fsx foo' on the nfs filesystem for a few minutes. I just ran an fsx cycle on my desktop machine over a TCP mount, and it seemed to work fine: [EMAIL PROTECTED]: /usr/src/tools/regression/fsx] ./fsx /tmp/nfs/x truncating to largest ever: 0x13e76 truncating to largest ever: 0x2e52c truncating to largest ever: 0x3c2c2 truncating to largest ever: 0x3f15f truncating to largest ever: 0x3fcb9 truncating to largest ever: 0x3fe96 truncating to largest ever: 0x3ff9d truncating to largest ever: 0x3 skipping zero size read skipping zero size write skipping zero size write ^Csignal 2 testcalls = 166863 Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: IDE DVD playback on 5.1-CURRENT
Martin wrote: On Wed, 2003-10-01 at 08:24, Lars Eggert wrote: Your change below makes mplayer work here again, too. Did you ever submit it for inclusion in the ports tree? Why? I noticed I have this problem, too, but I just added: link acd0 rdvd As a further rule in devfs.conf. It works fine. No need to patch the port, in my opinion. Because it's a bug in mplayer, and should be fixed there. Mplayer should not second-guess the user and blindly insert an "r" into a perfectly valid device name (/dev/acd0 -> /dev/racd0.) Also, fixing the port fixes it for everybody, while this change needs to be made by everyone manually. (Unless you propose adding this to the default devfs rules.) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: IDE DVD playback on 5.1-CURRENT
Peter Kostouros wrote: I had a similar problem when running mplayer with recent kernels. My problem was that although I was executing mplayer with -dvd-device /dev/acd0, the program was trying to open /dev/racd0. I modified main/libmpdvdkit2/dvd_reader.c and sure enough everything is OK. I hope the following helps: Your change below makes mplayer work here again, too. Did you ever submit it for inclusion in the ports tree? (Aside: The strange thing is that a unpatched mplayer worked fine until this afternoon, too. Between playing one DVD and the next, the break occured. This is a new drive. I think I remember the drives having some grace period before they lock in a region code? Could this matter?) Lars #if defined(SYS_BSD) /* FreeBSD /dev/(r)(a)cd0c (a is for atapi), recomended to _not_ use r OpenBSD /dev/rcd0c, it needs to be the raw device NetBSD /dev/rcd0[d|c|..] d for x86, c (for non x86), perhaps others Darwin /dev/rdisk0, it needs to be the raw device BSD/OS /dev/sr0c (if not mounted) or /dev/rsr0c ('c' any letter will do) */ static char *bsd_block2char( const char *path ) { char *new_path; #if 0 /* If it doesn't start with "/dev/" or does start with "/dev/r" exit */ if( strncmp( path, "/dev/", 5 ) || !strncmp( path, "/dev/r", 6 ) ) return (char *) strdup( path ); /* Replace "/dev/" with "/dev/r" */ new_path = malloc( strlen(path) + 2 ); strcpy( new_path, "/dev/r" ); strcat( new_path, path + strlen( "/dev/" ) ); #endif new_path = strdup(path); return new_path; } #endif Adam K Kirchhoff wrote: Again, no luck. From vlc: [0141] main input: playlist item `dvdold:///dev/[EMAIL PROTECTED],1' [0141] dvd input error: dvdcss cannot open device libdvdread: Using libdvdcss version 1.2.5 for DVD access libdvdread: Could not open /dev/acd0 with libdvdcss. libdvdread: Can't open /dev/acd0 for reading [0141] dvdread input error: libdvdcss cannot open source [0141] vcd input error: no movie tracks found [0141] main input error: no suitable access module for `/://dvdold:///dev/[EMAIL PROTECTED],1 From mplayer: Playing DVD title 1 libdvdread: Could not open device with libdvdcss. libdvdread: Can't open /dev/acd0 for reading Couldn't open DVD device: /dev/acd0 From ogle: libdvdread: Using libdvdcss version 1.2.5 for DVD access libdvdread: Could not open /dev/acd0c with libdvdcss. libdvdread: Can't open /dev/acd0c for reading ERROR[ogle_nav]: faild to open/read the DVD Yet the same DVD in the firewire drive works just fine. I can certainly try recompiling the applications but, frankly, I'm really doubtful that will solve the problem :-( Adam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
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=82005 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: f2e0 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: f330 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=82105 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: f030 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=82005 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: f2e0 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: f330 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: X10 Wireless Technology Inc USB Receiver
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 (This is with ehci disabled.) Mmm - looks you are right, but your init data seems to be different. 0x8001 vs 0x8003 and 0x8007. I think the only difference is that I prepended the 0x80 directly, which the Linux driver fudges in front in send_packet. Interesting is the calculation of transfer_buffer_length in send_packet(), which would result in 4 for init1 and 8 for init2. I interpret this that the last byte from init1 doesn't get written and your packets don't fit into that sheme. I think they do, see the Windows dump. The source looks very confusing to me, but maybe that because of my current localtime()... No, it's not :-) After I reading that driver, I know why I like the BSD sources. The Windows log could help as it's at least readable and familar. It's attached, in whatever format snoopy (http://sourceforge.net/projects/usbsnoop/) saves it. It shows two writes with this data: TransferBuffer: 0x0005 (5) length : 80 01 00 20 14 TransferBuffer: 0x0008 (8) length : 80 01 00 20 14 20 20 20 Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute USBLog1.usblog Description: Binary data smime.p7s Description: S/MIME Cryptographic Signature
Re: X10 Wireless Technology Inc USB Receiver
Bernd, Bernd Walter wrote: On Sun, Sep 21, 2003 at 10:35:33AM -0700, Lars Eggert wrote: static char init1[]= { 0x80, 0x01, 0x00, 0x20, 0x14 }; static char init2[]= { 0x80, 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 }; Are you shure that the above is correct data for the device? The IO error could also be returned from the device. Relatively. It's in the Linux driver, and I've used a Windows USB snooper to verify that ATI's Windows driver writes the same two chunks. What does USB_DEBUG with hw.usb.debug=2 and hw.usb.ugen.debug=2 say? Bevor I download the complete source you mentioned, can you give us the lines that lead to the above command? I'm away from that machine until later, I'll make sure to send the output when I get back. The Linux driver is actually pretty short. Here's the source: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gatos/ati_remote/ati_remote.c?annotate=1.9 The init packets get written at line 440. I don't know, but it could also depend on the controller you use. E.g. ehci currently doesn't support interrupt endpoints at all. Ah. Yes, this is with ehci coupled to ohci. Should I try to disable ehci for now? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: X10 Wireless Technology Inc USB Receiver
Hi, I'm trying to get the USB RF remote control that comes with some ATI Wonder cards to do something meaningful under -current. It shows up as an "X10 Wireless Technology Inc USB Receiver" with three devices: /dev/ugen0, and the corresponding input (/dev/ugen0.1) and output endpoints (/dev/ugen/0.2). Also see the attached usbctl output. Simply reading from the input endpoint /dev/ugen0.1 doesn't work. This page (http://remotew.free.fr/linux_en.htm) points at the Gatos project, which has a Linux driver (ati_remote) that seems to make the remote show up as a USB keyboard: http://sourceforge.net/project/showfiles.php?group_id=12629 That driver sends a couple of magic bytes to the device during initialization. I'm trying to do the same from userland: static char init1[]= { 0x80, 0x01, 0x00, 0x20, 0x14 }; static char init2[]= { 0x80, 0x01, 0x00, 0x20, 0x14, 0x20, 0x20, 0x20 }; int main(int argc, char *argv[]) { int out = open("/dev/ugen0.2", O_WRONLY); if (out == -1) { perror("ugen0.2"); goto done; } if (write(out, init1, sizeof init1) == -1) { perror("write init1"); goto done; } if (write(out, init2, sizeof init2) == -1) { perror("write init1"); goto done; } done: close(out); } Really simply. Here's what happens when I run it: write init1: Input/output error it feels like I'm missing something extremely obvious, but I'm new to the USB internals. The two endpoints are "interrupt" endpoints. I'm not sure what that signifies, but I heard writing to them on -stable is broken, but on -current it should work. Any ideas? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute DEVICE addr 2 DEVICE descriptor: bLength=18 bDescriptorType=device(1) bcdUSB=1.10 bDeviceClass=0 bDeviceSubClass=0 bDeviceProtocol=0 bMaxPacketSize=8 idVendor=0x0bc7 idProduct=0x0004 bcdDevice=100 iManufacturer=1(X10 Wireless Technology Inc) iProduct=2(USB Receiver) iSerialNumber=0() bNumConfigurations=1 CONFIGURATION descriptor 0: bLength=9 bDescriptorType=config(2) wTotalLength=32 bNumInterface=1 bConfigurationValue=1 iConfiguration=0() bmAttributes=80 bMaxPower=2 mA INTERFACE descriptor 0: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0 bNumEndpoints=2 bInterfaceClass=255 bInterfaceSubClass=0 bInterfaceProtocol=0 iInterface=0() ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in bmAttributes=interrupt wMaxPacketSize=8 bInterval=10 ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=2-out bmAttributes=interrupt wMaxPacketSize=8 bInterval=10 current configuration 1 smime.p7s Description: S/MIME Cryptographic Signature
Re: ATAng no good for me
Daniel Eischen wrote: On Sat, 20 Sep 2003, Soren Schmidt wrote: It seems Daniel Eischen wrote: On a kernel built just a few hours ago, it hangs on boot right after: acd0: CDROM at ata0-master PIO4 Get atapicam out and see if that helps.. No, using latest sources, with or without atapicam, does not solve the problem. It still hangs. As a datapoint, I experienced the hang with atapicam, too. Removing it helped in my case. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Portupgrade problems
Alastair G. Hogge wrote: Hey all, I haven't updated my ports for a few weeks and after after a recent cvsup of world and the ports tree I tried to run portupgrade -aCC and was displayed with the following: n /var/db/pkg ... - 318 packages found (-8 +6) (...)/usr/local/lib/ruby/site_ruby/1.6/ports.rb:4:in `require': /usr/loc al/lib/ruby/site_ruby/1.6/portinfo.rb:98: unterminated string meets end of file (SyntaxError) ... Try "pkgdb -fu". Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: HEADS UP! ATAng committed
Hi, Lars Eggert wrote: Soren Schmidt wrote: ATAng has just been committed. You need to make world after this update as atacontrol etc needs to pick up the changes. Funky boot messages, but the system is usable after. This is with today's -current: atapci0: port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ... ad0: 78167MB [158816/16/63] at ata0-master UDMA100 ata1-slave: WARNING - ATA_IDENTIFY recovered from missing interrupt acd0: CDRW at ata1-master UDMA33 ad3: WARNING - SETFEATURES recovered from missing interrupt ad3: WARNING - SETFEATURES recovered from missing interrupt ad3: WARNING - SET_MULTI recovered from missing interrupt ad3: WARNING - SETFEATURES recovered from missing interrupt ad3: 3584MB [585/112/112] at ata1-slave PIO0 ad3: WARNING - READ_MUL recovered from missing interrupt ad3: WARNING - READ_MUL recovered from missing interrupt ad3: WARNING - READ_MUL recovered from missing interrupt Note that I have no ad3, only ad0 and acd0, which are masters on the primary and secondary channels as probed above. with today's -current (as opposed to 8/27, which was running when I sent the previous email), the system panics on boot: GEOM: create disk ad0 dp=0xc63b9e70 ad0: 78167MB [158816/16/63] at ata0-master UDMA100 acd0: CDRW at ata1-master UDMA33 ad3: WARNING - SETFEATURES recovered from missing interrupt ad3: WARNING - SETFEATURES recovered from missing interrupt ad3: WARNING - SETFEATURES recovered from missing interrupt GEOM: create disk ad3 dp=0xc64d6170 Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; lapic.id = instruction pointer = 0x8:0xc03067d0 stack pointer = 0x10:0xc070fc1c frame pointer = 0x10:0xc070fcac code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 18 trap, code=0 Stopped at __qdivrem+0x3e: divl%ecx,%eax db> Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: HEADS UP! ATAng committed
Soren Schmidt wrote: ATAng has just been committed. You need to make world after this update as atacontrol etc needs to pick up the changes. Funky boot messages, but the system is usable after. This is with today's -current: atapci0: port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ... ad0: 78167MB [158816/16/63] at ata0-master UDMA100 ata1-slave: WARNING - ATA_IDENTIFY recovered from missing interrupt acd0: CDRW at ata1-master UDMA33 ad3: WARNING - SETFEATURES recovered from missing interrupt ad3: WARNING - SETFEATURES recovered from missing interrupt ad3: WARNING - SET_MULTI recovered from missing interrupt ad3: WARNING - SETFEATURES recovered from missing interrupt ad3: 3584MB [585/112/112] at ata1-slave PIO0 ad3: WARNING - READ_MUL recovered from missing interrupt ad3: WARNING - READ_MUL recovered from missing interrupt ad3: WARNING - READ_MUL recovered from missing interrupt Note that I have no ad3, only ad0 and acd0, which are masters on the primary and secondary channels as probed above. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: panic with CF drive + USB reader
Bernd, . Seems that handling the stalled condition failed. Can you try the following patch: I was *just* going to write you saying it was still running with this patch, which would have been the longest yet. But then I saw these messages: umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed initiate_write_filepage: already started initiate_write_filepage: already started initiate_write_filepage: already started umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed initiate_write_filepage: already started And the box paniced again: panic: initiate_write_inodeblock_ufs2: already started cpuid = 0; lapic.id = Stack backtrace: backtrace(c033157d,0,c0341a7f,e96a1ab0,100) at backtrace+0x17 panic(c0341a7f,c01bc427,c7dabdf4,e96a1ad0,e96a1ad0) at panic+0x13d initiate_write_inodeblock_ufs2(c6f4cb00,d29060b8,c01fd879,0,d29060b8) at initiate_write_inodeblock_ufs2+0x68f softdep_disk_io_initiation(d29060b8,c17fbf30,e96a1bb4,c01fda2b,d29060b8) at softdep_disk_io_initiation+0x80 spec_xstrategy(c6d88490,d29060b8,e96a1bb4,c017dfcc,e96a1be0) at spec_xstrategy+0x104 spec_specstrategy(e96a1be0,e96a1bfc,c01f8550,e96a1be0,1) at spec_specstrategy+0x1b spec_vnoperate(e96a1be0,1,c6bfc800,d2a5f680,e96a1bdc) at spec_vnoperate+0x18 bwrite(d29060b8,100,c63304c0,e96a1c3c,80012) at bwrite+0x403 vfs_bio_awrite(d29060b8,80012,0,c63304c0,c017dfcc) at vfs_bio_awrite+0x27b vop_stdfsync(e96a1cdc,0,c6d88490,e96a1ca4,c017dfcc) at vop_stdfsync+0x1b1 spec_fsync(e96a1cdc,e96a1d18,c020b613,e96a1cdc,20002) at spec_fsync+0x31 spec_vnoperate(e96a1cdc,20002,c63304c0,c0335c1b,0) at spec_vnoperate+0x18 sched_sync(0,e96a1d48,0,0,0) at sched_sync+0x1e3 fork_exit(c020b430,0,e96a1d48) at fork_exit+0xb2 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe96a1d7c, ebp = 0 --- Debugger("panic") Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0 It seems that this happens under light or no load only. I had been doing a heavy cycle of dump/restore/dd, etc, and all was well. Could it be that the MicroDrive does some kind of internal power management that delays its reponses some, and the kernel doesn't expect that? Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: panic with CF drive + USB reader
Nate Lawson wrote: umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed panic: softdep_setup_freeblocks: inode busy da2 at umass-sim0 bus 0 target 0 lun 0 da2: Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: 1027MB (2104705 512 byte sectors: 255H 63S/T 131C) Your microdrive may need some USB quirks. Try RS_NO_CLEAR_UA (see /sys/dev/usb/umass.c for examples). RS_NO_CLEAR_UA doesn't seem to help: umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed initiate_write_filepage: already started initiate_write_filepage: already started initiate_write_filepage: already started It hasn't crashed yet, but solme funky things are going on. Thanks, I'll try that. It also complains during boot about not supporting Get Max Lun, so that's a quirk also. No, that's likely not a quirk. Complaining is ok if it doesn't cause actual problems (i.e. can't mount partition). Try one quirk at a time until it works. OK. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: panic with CF drive + USB reader
Here's another, different one: (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da2:umass-sim0:0:0:0): SCSI Status: Check Condition (da2:umass-sim0:0:0:0): UNIT ATTENTION asc:0,0 (da2:umass-sim0:0:0:0): No additional sense information (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data) umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed /cf: bad dir ino 47104 at offset 0: mangled entry panic: ufs_dirbad: bad dir cpuid = 0; lapic.id = Stack backtrace: backtrace(c033157d,0,c03429a4,eb9e8810,100) at backtrace+0x17 panic(c03429a4,c6ae0eb0,b800,0,c034295e) at panic+0x13d ufs_dirbad(c7771604,0,c034295e,0,eb9e888c) at ufs_dirbad+0x53 ufs_lookup(eb9e894c,eb9e8988,c01ff704,eb9e894c,eb9e8bf0) at ufs_lookup+0x416 ufs_vnoperate(eb9e894c,eb9e8bf0,eb9e8c04,0,c6b09130) at ufs_vnoperate+0x18 vfs_cache_lookup(eb9e89cc,eb9e89e8,c020460b,eb9e89cc,c6b09130) at vfs_cache_look u up+0x2d8 ufs_vnoperate(eb9e89cc,c6b09130,0,c6b09130,c6b09130) at ufs_vnoperate+0x18 lookup(eb9e8bdc,c66cc800,400,eb9e8bf8,c6b09130) at lookup+0x2e0 namei(eb9e8bdc,1010002,c7add124,c6b09130,eb9e8a74) at namei+0x1e8 vn_open_cred(eb9e8bdc,eb9e8cdc,1a4,c6a0d400,4) at vn_open_cred+0x257 vn_open(eb9e8bdc,eb9e8cdc,1a4,4,c0201fe6) at vn_open+0x30 kern_open(c6b09130,8136dd8,0,1,1b6) at kern_open+0x15b open(c6b09130,eb9e8d14,c,8136000,3) at open+0x30 syscall(2f,2f,2f,0,bfbff994) at syscall+0x25e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5), eip = 0x28192f5f, esp = 0xbfbff318, ebp = 0xbfbff344 --- Debugger("panic") Again, I could not get a coredump. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
panic with CF drive + USB reader
Hi, this happens with an IBM MicroDrive mounted on a USB CF reader, -current from 8/19/03. I couldn't get a coredump: umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da2:umass-sim0:0:0:0): AutoSense Failed panic: softdep_setup_freeblocks: inode busy cpuid = 0; lapic.id = Stack backtrace: backtrace(c033157d,0,c0341434,e96a19a0,100) at backtrace+0x17 panic(c0341434,115af,1,e96a19f4,0) at panic+0x13d softdep_setup_freeblocks(c7b18690,0,0,800,e96a1a2c) at softdep_setup_freeblocks+0x5cc ffs_truncate(c7b35db0,0,0,0,c2198e80) at ffs_truncate+0x6be handle_workitem_remove(c733b680,0,2,c0208995,c6b45c00) at handle_workitem_remove+0x1a0 process_worklist_item(0,0,3f4a70b8,0,0) at process_worklist_item+0x184 softdep_process_worklist(0,20002,c63304c0,c0335c1b,0) at softdep_process_worklist+0xc0 sched_sync(0,e96a1d48,0,0,0) at sched_sync+0x3f7 fork_exit(c020b430,0,e96a1d48) at fork_exit+0xb2 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe96a1d7c, ebp = 0 --- Debugger("panic") These are the devices: da2 at umass-sim0 bus 0 target 0 lun 0 da2: Removable Direct Access SCSI-2 device da2: 1.000MB/s transfers da2: 1027MB (2104705 512 byte sectors: 255H 63S/T 131C) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ENE 4-in-1 card reader
M. Warner Losh wrote: In message: <[EMAIL PROTECTED]> Lars Eggert <[EMAIL PROTECTED]> writes: : However, even with a new kernel that has your latest commit, this device : is still unattached. I'm attaching pciconf and dmesg, maybe that'll be : of help? not likely. there's a different interface for the flash reader part that we don't have a driver for yet. there's a bit of IP hording going on at the moment relating to these new devices. I've requested a datasheet for these parts, but so far I've had no response yet. Great! I don't need this for anything special, but it's nice to know that it may at some point start working under FreeBSD. Let me know if you want me to test something then. Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
cdcontrol eject fails?
Hi, "cdcontrol -f acd0 eject" doesn't eject anything for this drive: acd0: DVD-R at ata0-slave UDMA33 However, with "device atapicam" an eject on the emulated cd0 device works fine. It doesn't work with acd0 whether or not atapicam is enabled. I could have sworn cdcontrol works for ATAPI drives. Any ideas? Thanks, Lars PS: Funny how many little things you find on a new machine... -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Recent changes to AC97 files breaks sound
Orion Hodson wrote: /-- Lars Eggert wrote: | What's weird is that everything looks like it should be playing - no | weird messages, no jumpy progress bar, etc. I'll double-check my cabling | again. | | One more thing: This board has a bunch of connectors, including regular | analog out and SPDIF. Right now, things are hooked up to the analog - is | it maybe playng out of the SPDIF? (Does that even work yet under FreeBSD?) Thanks for the info. I'm looking at the diff and not seeing what's happened here. I'll have to think some more, check the specs, and get back to you. I've booted into Windows, and sound plays. So it's not the cabling. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Recent changes to AC97 files breaks sound
Orion, Orion Hodson wrote: First off, apologies for the breakage. no problem - thanks for all the hard work you, Cameron and the others have put into the sound code! Before investing any time doing a register dump, can you just check whether your mixer now has an ogain control and that it is non-zero. I don't, and I have all of them max'ed: Mixer vol is currently set to 100:100 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 100:100 Mixer line is currently set to 100:100 Mixer mic is currently set to 100:100 Mixer cd is currently set to 100:100 Mixer rec is currently set to 100:100 Mixer line1is currently set to 100:100 Mixer phin is currently set to 100:100 Mixer phoutis currently set to 100:100 Mixer videois currently set to 100:100 Recording source: mic What's weird is that everything looks like it should be playing - no weird messages, no jumpy progress bar, etc. I'll double-check my cabling again. One more thing: This board has a bunch of connectors, including regular analog out and SPDIF. Right now, things are hooked up to the analog - is it maybe playng out of the SPDIF? (Does that even work yet under FreeBSD?) Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Recent changes to AC97 files breaks sound
Hi, Rudolf Cejka wrote: Glenn Johnson wrote (2003/08/21): sound no longer works. I reverted to the previous versions of these files to get sound back. I might have the same issue. Does "no longer work" means silence? Then I do. (Just got this box, so I don't know whether this was recently broken or not.) Here's my hardware: pcm0: port 0x9000-0x907f,0x9400-0x94ff irq 15 at device 2.7 on pci0 pcm0: Could you do ALC650 register dump? If you look into ftp://ftp.FreeBSD.cz/pub/FreeBSD-local/ich/ , you can see small how-to in DEBUG sections. Would the dump work/help for the SiS chip as well? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ENE 4-in-1 card reader
M. Warner Losh wrote: : > What's at device 16.0? : : [EMAIL PROTECTED]:16:0: class=0x060700 card=0x14111524 chip=0x14111524 rev=0x01 : hdr=0x02 : vendor = 'ENE Technology Inc' : class= bridge : subclass = PCI-CardBus So is the the CB1410, CB1420, CB710 or CB720? With your new commit, it is detected as a CB720. Even before that commit, the PC card slot on this box worked. I have a Cisco Aironet 350 in there, because the experimental bcm Broadcom 4401 driver has issues with the onboard NIC. However, even with a new kernel that has your latest commit, this device is still unattached. I'm attaching pciconf and dmesg, maybe that'll be of help? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute z /usr/share/man/man1 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks, buffers remaining... 9 9 done cam: using minimum scsi_delay (100ms) Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #5: Fri Aug 22 02:44:57 PDT 2003 root@:/usr/src/sys/i386/compile/KERNEL Preloaded elf kernel "/boot/kernel/kernel" at 0xc062f000. Preloaded elf module "/boot/kernel/if_bcm.ko" at 0xc062f244. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc062f2f0. Timecounter "i8254" frequency 1193140 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2393.93-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff real memory = 520077312 (495 MB) avail memory = 498188288 (475 MB) Pentium Pro MTRR support enabled VESA: v3.0, 16384k memory, flags:0x0, mode table:0xc052d7a2 (122) VESA: SiS npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00f15e0 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 acpi_cpu1: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 2 INTB is routed to irq 10 pcib0: slot 2 INTA is routed to irq 11 pcib0: slot 2 INTC is routed to irq 15 pcib0: slot 3 INTA is routed to irq 5 pcib0: slot 3 INTB is routed to irq 6 pcib0: slot 3 INTC is routed to irq 9 pcib0: slot 3 INTD is routed to irq 9 pcib0: slot 14 INTA is routed to irq 10 pcib0: slot 14 INTA is routed to irq 10 pcib0: slot 15 INTA is routed to irq 15 pcib0: slot 16 INTA is routed to irq 11 pcib0: slot 16 INTB is routed to irq 3 pcib0: slot 19 INTA is routed to irq 15 agp0: mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pcib1: slot 0 INTA is routed to irq 11 pci1: at device 0.0 (no driver attached) isab0: at device 2.0 on pci0 isa0: on isab0 fwohci0: vendor=1039, dev=7007 fwohci0: <1394 Open Host Controller Interface> mem 0xdf00-0xdf000fff irq 10 at device 2.3 on pci0 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 00:e0:18:00:00:0b:c0:bf fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 if_fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:e0:18:0b:c0:bf sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=5, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) atapci0: port 0xa400-0xa40f,0xa800-0xa803,0xb000-0xb007,0xb400-0xb403,0xb800-0xb807 irq 11 at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pcm0: port 0x9000-0x907f,0x9400-0x94ff irq 15 at device 2.7 on pci0 pcm0: ohci0: mem 0xde80-0xde800fff irq 5 at device 3.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xde00-0xde000fff irq 6 at device 3.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub2: Mitsumi Electric Hub in Apple USB Keyboard, class 9/0, rev 1.10/2.11, addr 2 uhub2: 3 ports with 2 removable, bus powered ukbd0: Mitsumi Electric Apple USB Keyboard, rev 1.00/1.03, addr 3, iclass 3/1 kbd0 at ukbd0 ums0: Logitech USB-PS/2 Mouse, rev 1.00/1.20, ad
ENE 4-in-1 card reader
Hi, we've got an Asus Pundit here that has an onboard 4-in-1 memory card reader: [EMAIL PROTECTED]:16:1:class=0x050100 card=0x17241043 chip=0x05101524 rev=0x00 hdr=0x00 vendor = 'ENE Technology Inc' class= memory subclass = flash Is there a driver for this under -current yet? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: "got bad cookie" warnings/errors?
Emiel Kollof wrote: I've been seeing lots of these lately: got bad cookie vp 0xc2f40b68 bp 0xc929a1e8 got bad cookie vp 0xc318d124 bp 0xc91d4240 ... I grepped around, and it seems it has something to do with NFS (well, I found this being printf'ed in src/sys/nfsclient/nfs_bio.c I have two NFS machines from which I mount, a 4.8-STABLE machine and a NetBSD 1.6.1 box. I haven't seen any dataloss or panics. But still, should I be worried? How serious is this message? I can only say that (1) I've been getting these forever, on both -stable and -current, and (2) I personally have never lost any data. However, I have no clue as to why you and I get them, or what they signify. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: "got bad cookie" warnings/errors?
David Malone wrote: On Sat, Aug 09, 2003 at 09:15:45PM -0700, Lars Eggert wrote: I can only say that (1) I've been getting these forever, on both -stable and -current, and (2) I personally have never lost any data. However, I have no clue as to why you and I get them, or what they signify. I have a vague feeling they are related to a directory changing while it is being read, and might mean that the NFS client sees an inconsistent version of the directory. It's been a long time since I looked at it though. Sounds reasonable, but I'm not sure if is the case for me: My home directory is NFS mounted from a Solaris box, and gets modified only from a single client (my desktop) at a time. I get these "cookie" messages whenever I log out of X, when a lot of things get read and written to that mount. Since all those reads and writes originate on my FreeBSD desktop, I would expect its NFS client to keep its cache consitent in that case. But maybe not. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: spin lock sched lock held for > 5 seconds
John Baldwin wrote: On 01-Aug-2003 Lars Eggert wrote: Hi, got the following panic overnight running with all debugging options on (WITNESS, MUTEX_DEBUG, DIAGNOSTIC, INVARIANTS; WITNESS_SKIPSPIN off): panic: spin lock sched lock held by 0xc658e130 for > 5 seconds cpuid = 0; lapic.id = Stack backtrace: backtrace(c031d030,0,c031c4c5,df0dab8c,100) at backtrace+0x17 panic(c031c4c5,c031c62e,c658e130,c036f160,18b) at panic+0x13d _mtx_lock_spin(c036f160,2,c031a229,18b,c21b2ab0) at _mtx_lock_spin+0x83 _mtx_lock_spin_flags(c036f160,2,c031a229,18b,df0dac0c) at _mtx_lock_spin_flags+0xb9 statclock(df0dac00,df0dac44,c02d8a9c,0,c2198d00) at statclock+0x39 rtcintr(0) at rtcintr+0x4f Xfastunpend8(df0dacb8,c02d1f05,8,608,c0372e60) at Xfastunpend8+0x1c call_fast_unpend(8,608,c0372e60,ffc00034,0) at call_fast_unpend+0xd i386_unpend(c036f160,c21b0790,df0dacd0,c01b1ae0,df0dacec) at i386_unpend+0x8d cpu_unpend(df0dacec,c01a2534,c036f160,1,c031c2e2) at cpu_unpend+0x2d critical_exit(c036f160,1,c031c2e2,1bc,1) at critical_exit+0x2d _mtx_unlock_spin_flags(c036f160,0,c031ac9f,7c,c21b2ab0) at _mtx_unlock_spin_flags+0xbb idle_proc(0,df0dad48,c031ab89,312,c21b2ab0) at idle_proc+0xb0 fork_exit(c0199972,0,df0dad48) at fork_exit+0xc3 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf0dad7c, ebp = 0 --- Debugger("panic") timeout stopping cpus Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0 db> The machine is still in ddb, let me know if I can provide additional info. Try updating to a more recent current. I recently added some extra debugging here that will attempt to better show who owns the lock and where it was acquired. Same panic string, but a different call chain: spin lock sched lock held by 0xc21b2d10 for > 5 seconds exclusive spin mutex sched lock r = 0 (0xc036efc0) locked @ /usr/src/sys/kern/kern_mutex.c:512 panic: spin lock held too long cpuid = 3; lapic.id = 0300 Stack backtrace: backtrace(c031ce60,300,c031c305,df0d0c30,100) at backtrace+0x17 panic(c031c305,c21b2d10,c21b2d10,c036efc0,bc) at panic+0x13d _mtx_lock_spin(c036efc0,2,c031a037,bc,c21b2720) at _mtx_lock_spin+0xb4 _mtx_lock_spin_flags(c036efc0,2,c031a037,bc,c21b2720) at _mtx_lock_spin_flags+0xb9 hardclock_process(df0d0ca0,df0d0ce4,c02d7062,0,c0390018) at hardclock_process+0x3c forwarded_hardclock(0) at forwarded_hardclock+0x11 Xhardclock(df0d0d10,c01998d7,c036f000,2,c031aaad) at Xhardclock+0x52 cpu_idle(c036f000,2,c031aaad,5f,c21b2720) at cpu_idle+0x8 idle_proc(0,df0d0d48,c031a997,30e,0) at idle_proc+0x45 fork_exit(c0199892,0,df0d0d48) at fork_exit+0xc3 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdf0d0d7c, ebp = 0 --- Debugger("panic") timeout stopping cpus Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0 db> Machine is still in ddb, in case you'd like me to poke around some more. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Waiting on "allproc" w/ with non-sleepable locks held
Hi, yet another funky console message with today's -current: Waiting on "allproc" with the following non-sleepablelocks held: exclusive sleep mutex callout_dont_sleep r = 0 (0xc0371fa0) locked @ /usr/src/sys/kern/kern_timeout.c:223 Got this twice in a row; system didn't enter ddb so I got no trace. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
spin lock sched lock held for > 5 seconds
Hi, got the following panic overnight running with all debugging options on (WITNESS, MUTEX_DEBUG, DIAGNOSTIC, INVARIANTS; WITNESS_SKIPSPIN off): panic: spin lock sched lock held by 0xc658e130 for > 5 seconds cpuid = 0; lapic.id = Stack backtrace: backtrace(c031d030,0,c031c4c5,df0dab8c,100) at backtrace+0x17 panic(c031c4c5,c031c62e,c658e130,c036f160,18b) at panic+0x13d _mtx_lock_spin(c036f160,2,c031a229,18b,c21b2ab0) at _mtx_lock_spin+0x83 _mtx_lock_spin_flags(c036f160,2,c031a229,18b,df0dac0c) at _mtx_lock_spin_flags+0xb9 statclock(df0dac00,df0dac44,c02d8a9c,0,c2198d00) at statclock+0x39 rtcintr(0) at rtcintr+0x4f Xfastunpend8(df0dacb8,c02d1f05,8,608,c0372e60) at Xfastunpend8+0x1c call_fast_unpend(8,608,c0372e60,ffc00034,0) at call_fast_unpend+0xd i386_unpend(c036f160,c21b0790,df0dacd0,c01b1ae0,df0dacec) at i386_unpend+0x8d cpu_unpend(df0dacec,c01a2534,c036f160,1,c031c2e2) at cpu_unpend+0x2d critical_exit(c036f160,1,c031c2e2,1bc,1) at critical_exit+0x2d _mtx_unlock_spin_flags(c036f160,0,c031ac9f,7c,c21b2ab0) at _mtx_unlock_spin_flags+0xbb idle_proc(0,df0dad48,c031ab89,312,c21b2ab0) at idle_proc+0xb0 fork_exit(c0199972,0,df0dad48) at fork_exit+0xc3 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf0dad7c, ebp = 0 --- Debugger("panic") timeout stopping cpus Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0 db> The machine is still in ddb, let me know if I can provide additional info. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
vm/map LOR
Hi, with yesterday's -current: 1st 0xc6dfd094 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:434 2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:323 Stack backtrace: backtrace(c032000b,c082f110,c033362f,c033362f,c03334c6) at backtrace+0x17 witness_lock(c082f110,8,c03334c6,143,c082f0b0) at witness_lock+0x686 _mtx_lock_flags(c082f110,0,c03334c6,143,101) at _mtx_lock_flags+0xb5 _vm_map_lock(c082f0b0,c03334c6,143,c0374778,c03747a0) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,eb44db14,c02b0433) at kmem_malloc+0x3a page_alloc(c083a240,1000,eb44db07,101,0) at page_alloc+0x27 slab_zalloc(c083a240,101,c083a254,8,c0334e1e) at slab_zalloc+0xc2 uma_zone_slab(c083a240,101,c0334e1e,663,165) at uma_zone_slab+0xd9 uma_zalloc_internal(c083a240,0,101,6e7,0) at uma_zalloc_internal+0x4f uma_zfree_arg(c083a900,c6e31000,0,eb44dbc4,c029884d) at uma_zfree_arg+0x2a6 dev_pager_putfake(c6e31000,0,c0332b9e,be,c6dfd094) at dev_pager_putfake+0x35 dev_pager_dealloc(c6dfd094,1,c0334dcf,10c,0) at dev_pager_dealloc+0xb9 vm_pager_deallocate(c6dfd094,0,c0333f6c,261,1b2) at vm_pager_deallocate+0x3d vm_object_terminate(c6dfd094,0,c0333f6c,1b2,c6b894ec) at vm_object_terminate+0x1e5 vm_object_deallocate(c6dfd094,c082bd20,c6dfd094,c082bd20,eb44dca0) at vm_object_deallocate+0x35e vm_map_entry_delete(c6593e00,c082bd20,c033369d,897,c019f843) at vm_map_entry_delete+0x3c vm_map_delete(c6593e00,282e2000,282e3000,1000,282e2000) at vm_map_delete+0x3c3 vm_map_remove(c6593e00,282e2000,282e3000,0,c6b8a618) at vm_map_remove+0x55 munmap(c6ae24c0,eb44dd14,c0339293,3ee,2) at munmap+0x9e syscall(2f,2f,2f,f8000,1000) at syscall+0x260 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (73), eip = 0x28257aa7, esp = 0xbfbffc1c, ebp = 0xbfbffc48 --- Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
LOR during boot
Hi, I'm getting the following LOR on each boot, system works fine nevertheless: ... Timecounters tick every 10.000 msec ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled DUMMYNET initialized (011031) IPv6 packet filtering initialized, logging disabled IPsec: Initialized Security Association Processing. lock order reversal 1st 0xc03718e0 callout_dont_sleep (callout_dont_sleep) @ /usr/src/sys/kern/kern_timeout.c:223 2nd 0xc0370c80 allproc (allproc) @ /usr/src/sys/kern/sched_4bsd.c:254 Stack backtrace: backtrace(c032000b,c0370c80,c031c789,c031c789,c031e2e3) at backtrace+0x17 witness_lock(c0370c80,0,c031e2e3,fe,c06ec345) at witness_lock+0x686 _sx_slock(c0370c80,c031e2e3,fe,c03718e0,8) at _sx_slock+0xaa schedcpu(0,0,c031dfd6,df,60b) at schedcpu+0x3f softclock(0,0,c031acea,230,c21b03c8) at softclock+0x1ec ithread_loop(c2198d00,df0e0d48,c031ab89,312,c21b2d10) at ithread_loop+0x167 fork_exit(c019a4ba,c2198d00,df0e0d48) at fork_exit+0xc3 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf0e0d7c, ebp = 0 --- Debugger("witness_lock") Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0 db> c Expensive timeout(9) function: 0xc01be517(0) 0.231687267 s ata1-slave: timeout waiting for interrupt ata1-slave: ATA identify failed ad0: 78167MB [158816/16/63] at ata0-master UDMA100 acd0: CD-RW at ata1-master UDMA33 ... Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
panic: spin lock sched lock held
Hi, got this panic overnight. Machine was wedged solid and didn't enter ddb after the panic. I'll recompile with verbose diagnostics and see if it happens again. In the meantime, maybe the message will give someone a clue: panic: spin lock sched lock held by 0xca462390 for > 5 seconds cpuid = 0; lapic.id = Debugger("panic") Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: audigy 2
Yuriy, Yuriy Tsibizov wrote: Unfortunately your driver isn't very committable -- unfortunately you took it upon himself to totally reformat our emu10k1.c file in addition to embellishing it. So it is impossible to see what changes you really made to the driver. I don't suppose you've got a patch with the minimal number of changes to support audigy and audigy2? Old driver (emu10k1.c) was too big for me to work on it and was difficult to add MIDI support. I know that my driver will never go into the tree - sound@ decided to use Orlando Bassotto's work. His driver is much closer to original emu10k1.c that mine. that is a pity, I'd really like to see Audigy support in the tree. People create patches all the time and maintain them separately for some time, but the eventual goal should be inclusion in the main tree. Juggling a number of third-party patches when building a kernel is a pain (even though I understand the Linux folks do this a lot.) You would make many of us happy if your patch could be made committable. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ReiserFS
Brad Knowles wrote: At 9:50 AM -0700 2003/06/22, Lars Eggert wrote: Make the ReiserFS box an NFS server and mount it on FreeBSD to copy the data over. What if it's the same machine? What if they have only the one machine, so they can't even copy it over to another one, just to copy it back? Ah, good point. Run one inside VMware in the other, and do the NFS mount over the emulated network link. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ReiserFS
Simon Watson wrote: Are there any plans for including reiserFS support in FreeBSD? I plan to move my desktop over to FreeBSD 5 at some point, but I can't seem to find any mention of reiser for it. Maybe I should have clarified this, I'm only after readonly support - just enough to be able to successfully move my data over to UFS. Make the ReiserFS box an NFS server and mount it on FreeBSD to copy the data over. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: 5.1-RELEASE TODO
Robert Watson wrote: | |---++---+---| | || | The 20030228 vendor | | Fresh ACPI-CA | -- | --| sources have been | | import|| | imported. Further testing | | || | is appreciated. | |---++---+---| FYI, I still see the ACPI messages described in the "Re: ACPI-0293 (and 0166) errors"-thread on -current ca. 5/9/2003 on yesterday's -current. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
i2c modules not hooked up to the build?
Hi, is there a specific reason why the i2c modules aren't hooked up to the build in sys/modules/Makefile? diff -u -r1.324 Makefile --- Makefile2003/05/31 18:36:40 1.324 +++ Makefile2003/06/01 19:11:36 @@ -177,6 +177,7 @@ gnufpu \ hea \ hfa \ + i2c \ ibcs2 \ ie \ linprocfs \ Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Libthr stable enough for testing
Valentin Nechayev wrote: Fri, May 30, 2003 at 17:38:04, larse (Lars Eggert) wrote about "Re: Libthr stable enough for testing": LE> I tried, but the following is a surefire way to freeze my SMP box solid LE> at the moment (with today's libthr): SCHED_ULE or SCHED_4BSD? SCHED_4BSD -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Libthr stable enough for testing
Mike Makonnen wrote: I have committed some changes to libthr today. All but one of them were bug fixes, so I encourage everyone to update their source. ... I'll try to get a dump of the exact error messages when I have access to the box again in a few days. Please. I tried, but the following is a surefire way to freeze my SMP box solid at the moment (with today's libthr): 1. symlink libc_r to libthr 2. portupgrade -f gnomepanel 3. start gnome 4. machine freezes solid while gnome splash screen shows To resurrect: 1. remove libthr symlink 2. portupgrade -f gnomepanel 3. start gnome, works fine I could never reproduce the symptoms from a few days ago, where some pieces (i.e. gnomepanel) would not start giving an error message, but the rest of gnome came up, and the machine didn't freeze. (And "freeze" == ping fails and no panic showing on a serial console.) Any ideas what else to try? Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Libthr stable enough for testing
Mike Makonnen wrote: Most major locking work in libthr is finished. I believe it is stable enough now that it can be used for most applications[1]. I would appreciate it if people would try it out and report any bugs. I had been running with libc_r symlinked to libthr for a few days with no problems, and rebuilt some ports during that time. The machine (SMP) would sometimes freeze solid (no panic). I symlinked libc_r back to the original library, and from then on, starting gnomepanel and some other gnome pieces would fail due to errors about libthr. I couldn't find them in any log file right now, but I think I remember one was about getpwuid_r not being found. (The ports that caused problems were gnome 2.3 beta ports from the marcuscom CVS tree.) From what I understand, libthr should be a drop-in replacement for libc_r, so I was surprised to see this, but maybe I misunderstood? The problem was fixed by building/reinstalling the problematic ports without libthr symlinked into place. I'll try to get a dump of the exact error messages when I have access to the box again in a few days. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Yet another libthr crash
Gordon Tetlow wrote: No core dump from this one. Privoxy seems to be a good app to test multiple io threads and is simple enough to be debug. The source is also pretty Linux-centric, so some issues you finds may be related to that. (But I am all for fixing privoxy on -current, so I can start using it instead of guidescope, which fails to reap its kids due to some linux emulator change - see "zombies from linux binaries" thread on -current, circa 10/01/02.) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
an0 messages
Hi, I'm seeing these messages on a -current from last weekend: an0: discard oversize frame (ether type 0 flags 3 len 1522 > max 1514) an0: discard oversize frame (ether type 0 flags 3 len 1530 > max 1514) an0: record length mismatch -- expected 104, got 852 for Rid ff11 an0: record length mismatch -- expected 132, got 172 for Rid ff00 an0: record length mismatch -- expected 156, got 158 for Rid ff10 The first two may be to weird packets floating around the IETF network, but the "Rid" ones I see on a clean network, too. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: devstat_end_transaction: HELP!! busy_count for da1 is < 0 (-1)!
On 3/14/2003 7:46 AM, Ryan Dooley wrote: Didn't actually fix things for me :-( The system still paniced (rsync'ing data from the production file server. I was having a moment. I hadn't set dumpdev in /etc/rc.conf so the next time it happens I should have a crash dump to extract more information with. This might be a different problem, mine never panic'ed, just got toins of these messages. Lars Yes, I just got this myself today. I overlooked that devstat is not locked when I moved the devstat to geom_disk. Expect a patch tonight. There is a patch which can be tried at: http://phk.freebsd.dk/patch/ken.patch Seeing the same messages, going through a buildworld w/the patch now and will let you know if it helps. Seems to fix things for me! -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: devstat_end_transaction: HELP!! busy_count for da1 is < 0 (-1)!
Lars Eggert wrote: Poul-Henning Kamp wrote: Yes, I just got this myself today. I overlooked that devstat is not locked when I moved the devstat to geom_disk. Expect a patch tonight. There is a patch which can be tried at: http://phk.freebsd.dk/patch/ken.patch Seeing the same messages, going through a buildworld w/the patch now and will let you know if it helps. Seems to fix things for me! Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: devstat_end_transaction: HELP!! busy_count for da1 is < 0 (-1)!
Poul-Henning Kamp wrote: Yes, I just got this myself today. I overlooked that devstat is not locked when I moved the devstat to geom_disk. Expect a patch tonight. There is a patch which can be tried at: http://phk.freebsd.dk/patch/ken.patch Seeing the same messages, going through a buildworld w/the patch now and will let you know if it helps. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Gnome2 terminal will not work right
On 3/7/2003 11:50 PM, Marcel Moolenaar wrote: On Fri, Mar 07, 2003 at 11:30:34PM -0800, Lars Eggert wrote: this may be unrelated, but for about ten days or so, I have problems where gnometerminal will stop updating after a while. I can still use the menus, close it, etc. - but all output is suspended. Most of the time, selecting "Reset" from the menu repeatedly will eventually get me back to a working state again. It also seems that pasting multi-line text into a gnometerminal (as opposed to typing or it displaying output) will trigger this frequently. Me too I tend to think it happens more often with maximized windows than not and also when long lines are involved. A reset most of the time gets me back, but I do occasionally have to kill gnome-terminal completely when all the terminals are dead. Unfortunately I don't have the time to dig into it, but I'm probably going to switch window manager and see if that makes a difference. For some reason I'm suspicious about Metacity. Not necessarily because of this... I also switched to a TrueType font for gnometerminals (bitstream-vera) around the same time, so maybe that's a factor, too. As for window managers, I use sawfish (and have been, for a long time before the problem.) Also (unrelated?), it seems that X eats up a LOT of CPU with antialiases TrueType fonts in terminals, compared to good, old lucida-typewriter. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Gnome2 terminal will not work right
Hi, this may be unrelated, but for about ten days or so, I have problems where gnometerminal will stop updating after a while. I can still use the menus, close it, etc. - but all output is suspended. Most of the time, selecting "Reset" from the menu repeatedly will eventually get me back to a working state again. It also seems that pasting multi-line text into a gnometerminal (as opposed to typing or it displaying output) will trigger this frequently. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: cvs commit: src/sys/kern kern_lock.c
Mike Makonnen wrote: jeff2003/02/16 02:39:49 PST Modified files: sys/kern kern_lock.c Log: - Add a WITNESS_SLEEP() for the appropriate cases in lockmgr(). Revision ChangesPath 1.64 +7 -0 src/sys/kern/kern_lock.c I now get the following: Same here, FWIW. rebka# /daemon/build/current/rebka/src/sys/kern/kern_lock.c:239: could sleep with "buf queue lock" locked from /daemon/build/current/rebka/src/sys/kern/vfs_bio.c:2143 Debugger("witness_sleep") Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db> tr Debugger(c04a73dc,c04e005e,ef,c04e4d42,c04e769b) at Debugger+0x54 witness_sleep(1,c172c708,c04e005e,ef,c09f11e0) at witness_sleep+0x123 lockmgr(c172c7cc,10001,c172c708,c09f11e0,12) at lockmgr+0x71 vop_sharedlock(c5bfdc98,0,c04e95be,35c,c02efcf1) at vop_sharedlock+0x7d vn_lock(c172c708,12,c09f11e0,85f,c05b1d00) at vn_lock+0xeb flushbufqueues(c05b1d00,0,c04e765b,11e,64) at flushbufqueues+0xfb buf_daemon(0,c5bfdd48,c04df6c2,365,0) at buf_daemon+0xd5 fork_exit(c033e2e0,0,c5bfdd48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc5bfdd7c, ebp = 0 --- -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
lock panic when UDF mounting
Hi, got this when trying to mount_udf a DVD+RW, could not get a crashdump unfortunately: panic: lockmgr: locking against myself cpuid = 0; lapic.id = Debugger("panic") Stopped at Debugger+0x5a: xchgl %ebx,in_Debugger.0 db> trace Debugger(c0349145,0,c0347804,eb5309dc,1) at Debugger+0x5a panic(c0347804,0,c034776c,ee,100) at panic+0x12f lockmgr(c8529e04,1030002,c8529d50,c6c16540,eb530a24) at lockmgr+0x533 vop_stdlock(eb530a40,eb530a60,c02197e5,eb530a40,0) at vop_stdlock+0x2c vop_defaultop(eb530a40,0,c0350674,35c,c01afd38) at vop_defaultop+0x18 vn_lock(c8529d50,20002,c6c16540,86,0) at vn_lock+0xa5 udf_hashins(c85a2000,eb530ab4,c6c16540,800,0) at udf_hashins+0x89 udf_vget(c66d2600,c0,2,eb530b20,0) at udf_vget+0x238 udf_root(c66d2600,eb530b20,c034fa72,2ee,100) at udf_root+0x3e vfs_nmount(c6c16540,1,eb530cb0,0,8056c6b) at vfs_nmount+0x623 nmount(c6c16540,eb530d10,c03653af,407,ca6695cc) at nmount+0xcd syscall(2f,2f,2f,bfbffbbe,bfbffaac) at syscall+0x3c6 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (378, FreeBSD ELF32, nmount), eip = 0x80493db, esp = 0xbfbff60c, ebp = 0xbfbffa80 --- Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Page fault on disk-less machine
Terry Lambert wrote: Scott Long wrote: Guys, this problem has already been identified. I posted a patch last night to cvs-all@ that fixes this, although it's still not totally correct so I haven't committed it yet. This one, I imagine. Thanks! http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1225336+0+current/cvs-all It wasn't clear that this was the same problem, with the other recent potentially destabilizing commits. I guess PHK, Lars, and Craig should try applying this, and seeing if it fixes things for them... Tried it, and it does not fix the panic for me. There must be another problem. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Page fault on disk-less machine
On 2/19/2003 8:23 PM, Scott Long wrote: Guys, this problem has already been identified. I posted a patch last night to cvs-all@ that fixes this, although it's still not totally correct so I haven't committed it yet. Great, thanks! Though it might have been a good idea to CC current@ - I'd have seen it there. (I filter cvs-all@ for pieces of the tree I'm interested in, and your mail must have been nuked.) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: panic starting gnome
Terry Lambert wrote: Debug: > [excellent kernel-debugging recipe snipped] Here's a backtrace of a crashdump that should be more helpful: Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01b28c6 stack pointer = 0x10:0xeb3b17c0 frame pointer = 0x10:0xeb3b17e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2104 (gconf-sanity-check-) panic: from debugger cpuid = 0; lapic.id = Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 0; lapic.id = instruction pointer = 0x8:0xc03019ea stack pointer = 0x10:0xeb3b1534 frame pointer = 0x10:0xeb3b1540 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= IOPL = 0 current process = 2104 (gconf-sanity-check-) panic: from debugger cpuid = 0; lapic.id = boot() called on cpu#0 Uptime: 4m49s Dumping 1023 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumpsys(&dumper); (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc01bc00e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0xc01bc627 in panic (fmt=0xc0349b8d "from debugger") at /usr/src/sys/kern/kern_shutdown.c:542 #3 0xc0148192 in db_panic () at /usr/src/sys/ddb/db_command.c:448 #4 0xc0147fcc in db_command (last_cmdp=0xc037f9a0, cmd_table=0x0, aux_cmd_tablep=0xc0376fb8, aux_cmd_tablep_end=0xc0376fbc) at /usr/src/sys/ddb/db_command.c:346 #5 0xc014820a in db_command_loop () at /usr/src/sys/ddb/db_command.c:470 #6 0xc014af96 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72 #7 0xc0301697 in kdb_trap (type=12, code=0, regs=0xeb3b1780) at /usr/src/sys/i386/i386/db_interface.c:166 #8 0xc031a590 in trap_fatal (frame=0xeb3b1780, eva=0) at /usr/src/sys/i386/i386/trap.c:839 #9 0xc031a2da in trap_pfault (frame=0xeb3b1780, usermode=0, eva=52) at /usr/src/sys/i386/i386/trap.c:758 #10 0xc0319e95 in trap (frame= {tf_fs = -1038483432, tf_es = 16, tf_ds = -1070202864, tf_edi = 158, tf_esi = 52, tf_ebp = -348448800, tf_isp = -348448852, tf_ebx = 0, tf_edx = -966573056, tf_ecx = -966602272, tf_eax = -966602272, tf_trapno = 12, tf_err = 0, tf_eip = -1071961914, tf_cs = 8, tf_eflags = 66178, tf_esp = 0, tf_ss = -1070141731}) at /usr/src/sys/i386/i386/trap.c:445 #11 0xc0302ff8 in calltrap () at {standard input}:97 #12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158 #13 0xc021bcfc in vn_open_cred (ndp=0xeb3b1a44, flagp=0xeb3b1a0c, cmode=0, cred=0xc2195e80) at /usr/src/sys/kern/vfs_vnops.c:185 #14 0xc6acffb4 in ?? () #15 0xc01a06b3 in closef (fp=0x2, td=0x0) at vnode_if.h:1225 #16 0xc01a0054 in fdfree (td=0xc662d1e0) at /usr/src/sys/kern/kern_descrip.c:1433 #17 0xc01a5da2 in exit1 (td=0xc662d1e0) at /usr/src/sys/kern/kern_exit.c:254 #18 0xc01a5b11 in sys_exit () at /usr/src/sys/kern/kern_exit.c:116 #19 0xc031ab56 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 11095, tf_ebp = -1077937128, tf_isp = -348447372, tf_ebx = 679838148, tf_edx = 679837268, tf_ecx = 19, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 680166719, tf_cs = 31, tf_eflags = 582, tf_esp = -1077937172, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1033 #20 0xc030304d in Xint0x80_syscall () at {standard input}:139 ---Can't read userspace from dump, or kernel process--- (kgdb) up 12 #12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158 158 FILEDESC_LOCK(fdp); (kgdb) list 153 #endif 154 155 /* 156 * Get starting point for the translation. 157 */ 158 FILEDESC_LOCK(fdp); 159 ndp->ni_rootdir = fdp->fd_rdir; 160 ndp->ni_topdir = fdp->fd_jdir; 161 162 dp = fdp->fd_cdir; (kgdb) print ndp $2 = (struct nameidata *) 0x9e (kgdb) print fdp $1 = (struct filedesc *) 0x34 (kgdb) (kgdb) print p $3 = (struct proc *) 0x0 (kgdb) print td $5 = (struct thread *) 0xc662d1e0 (kgdb) print *td $7 = {td_proc = 0xc66307f0, [...] Very strange. namei() does essentially the following: p = td->td_proc; fdp = p->p_fd; td->td_proc seems reasonable, but p is 0. No idea how this could happen, any guesses? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Science
Re: Page fault on disk-less machine
Poul-Henning Kamp wrote: Fatal trap 12: page fault while in kernel mode FWIW, Craig Boston and me see the same panics (threads on -current: "panic starting gnome" and "VFS panic (possibly NFS-locking related?)"). fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x8:0xc018fd20 stack pointer = 0x10:0xc5fd27a4 frame pointer = 0x10:0xc5fd27c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 414 (cron) kernel: type 12 trap, code=0 Stopped at 0xc018fd20 = _mtx_lock_flags+0x40: cmpl$0xc02c1160,0(%ecx) db> trace _mtx_lock_flags(34,0,c02a5f56,9e,c0d9e1e0) at 0xc018fd20 = _mtx_lock_flags+0x40 namei(c5fd29b8,c5fd2c34,c044,c0570d00,c0d9e1e0) at 0xc01de06d = namei+0x16d vn_open_cred(c5fd29b8,c5fd2980,0,c0554e00,c02167cf) at 0xc01efce8 = vn_open_cred+0x258 nfs_dolock(c5fd2b98,758,c0e066a8,c0db3e10,c0e066a8) at 0xc02230f5 = nfs_dolock+0x2c5 nfs_advlock(c5fd2b98,0,c029ee60,761,c02b6800) at 0xc0222578 = nfs_advlock+0x58 fdrop_locked(c0db3e10,c0d9e1e0,c029ee60,69e,6002) at 0xc017fa28 = fdrop_locked+0x138 fdrop(c0db3e10,c0d9e1e0,c018fe06,c03b3e58,6002) at 0xc017f50e = fdrop+0x3e closef(c0db3e10,c0d9e1e0,c029ee60,595,0) at 0xc017f4bc = closef+0x12c fdfree(c0d9e1e0,0,c029f2f4,f2,1) at 0xc017ed46 = fdfree+0x116 exit1(c0d9e1e0,100,c029f2f4,73,c5fd2d40) at 0xc0184bc7 = exit1+0x3b7 sys_exit(c0d9e1e0,c5fd2d10,c02b0451,407,1) at 0xc0184801 = sys_exit+0x41 syscall(2f,2f,2f,0,) at 0xc027dc07 = syscall+0x257 Xint0x80_syscall() at 0xc026dabd = Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280c36bf, esp = 0xbfbffbec, ebp = 0xbfbffc08 --- db> Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: panic starting gnome
Craig Boston wrote: FWIW, this looks nearly identical to the panic I reported last night in the thread "VFS panic (possibly NFS locking related?)". I missed your message, just read it: yes, that sounds similar. I didn't manage to catch the ddb trace and had to work postmortem with a crash dump and gdb. But it looked just like here. Lars: Do you by any chance have your home directory on an NFS mount? Yes, I do. I think the reason that my gdb trace showed "??" instead of nfs_dolock is that I have nfsclient loaded as a module... Mine's loaded as a module, too. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
panic starting gnome
Hi, on today's -current, I get the following panic when starting gnome from xdm; a kernel from 2/10 works with today's world, so it must be something in the kernel that changed over the last week: Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = fault virtual address = 0x34 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01b28a6 stack pointer = 0x10:0xe91a57c0 frame pointer = 0x10:0xe91a57e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2444 (gconf-sanity-check-) kernel: type 12 trap, code=0 Stopped at _mtx_lock_flags+0x26: cmpl$0xc03884a0,0(%esi) db> mi_switch(c21b4980,0,c0354624,185,3f8) at mi_switch+0x240 ithread_schedule(c6283b80,1,c0305e16,c658e780,e91a55c0) at ithread_schedule+0x11c sched_ithd(d) at sched_ithd+0x41 Xintr13() at Xintr13+0xd3 --- interrupt, eip = 0xc02efea2, esp = 0xe91a55a4, ebp = 0xe91a55c0 --- siocnopen(e91a55d4,3f8,1c200,301,c01f040b) at siocnopen+0x12 siocncheckc(c03b4c80,78,e91a5608,c01f0358,e91a5624) at siocncheckc+0x40 cncheckc(e91a5624,c0149625,e91a57c8,c03a9ac8,e91a5634) at cncheckc+0x2c cngetc(e91a57c8,c03a9ac8,e91a5634,0,e91a57c8) at cngetc+0x18 db_readline(c03b1b80,78,e91a5658,c01481e6,c03499fb) at db_readline+0x65 db_read_line(c03499fb,c03a9ac8,e91a5658,c0148a28,0) at db_read_line+0x1a db_command_loop(c01b28a6,a0,0,e91a5680,0) at db_command_loop+0x46 db_trap(c,0,0,e91a56c0,5) at db_trap+0x66 kdb_trap(c,0,e91a5780,1,1) at kdb_trap+0x107 trap_fatal(e91a5780,34,c0372ee0,2e4,c658e780) at trap_fatal+0x250 trap_pfault(e91a5780,0,34,c03e0758,34) at trap_pfault+0x17a trap(c21a0018,10,c0360010,9e,34) at trap+0x3e5 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc01b28a6, esp = 0xe91a57c0, ebp = 0xe91a57e0 --- _mtx_lock_flags(34,0,c035cf5f,9e,c658e780) at _mtx_lock_flags+0x26 namei(e91a5a44,c0207d5a,c749458c,0,c658e780) at namei+0x134 vn_open_cred(e91a5a44,e91a5a0c,0,c2195e80,0) at vn_open_cred+0x53c nfs_dolock(e91a5c0c,c658e780,1b3,c03e0748,6001) at nfs_dolock+0x294 closef(c6673834,c658e780,c0353f03,595,c7375934) at closef+0x123 fdfree(c658e780,0,c03543ab,f2,73) at fdfree+0x1d4 exit1(c658e780,0,c03543ab,73,e91a5d40) at exit1+0x282 sys_exit(c658e780,e91a5d10,c0372ee0,407,c658de4c) at sys_exit+0x41 syscall(2f,2f,2f,0,2b57) at syscall+0x3d6 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1), eip = 0x288a853f, esp = 0xbfbffbec, ebp = 0xbfbffc18 --- Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
sio issue
Hi, lately, I end up in ddb when I connect my (unconnected) serial console cable to another machine. It's not critical, since "c" will continue fine, but it's annoying. Here's a trace: db> trace siointr1(c635a,0,c0361fb6,671,df101ce8) at siointr1+0x3c4 siointr(c635a000) at siointr+0x35 Xfastintr4() at Xfastintr4+0xba --- interrupt, eip = 0xc0301942, esp = 0xdf101ce8, ebp = 0xdf101ce8 --- cpu_idle(c037a9a0,2,c0346fa9,59,0) at cpu_idle+0x22 idle_proc(0,df101d48,c0346e65,361,0) at idle_proc+0x4e fork_exit(c01a6440,0,df101d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf101d7c, ebp = 0 --- db> c Could this commit be related at all? phk 2003/02/02 13:25:22 PST Modified files: sys/dev/sio sio.c Log: Set si_drv1 to our softc for all the six dev_t's we create for a serial port. Revision ChangesPath 1.383 +2 -0 src/sys/dev/sio/sio.c Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
pcm channel duplicate lock
Got thsi when opening gnomemeeting2 while having xmms playing: acquiring duplicate lock of same type: "pcm channel" 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 Debugger("witness_lock") Stopped at Debugger+0x5a: xchgl %ebx,in_Debugger.0 db> trace Debugger(c0328da1,c6283a54,c0532609,bf,eb3828ac) at Debugger+0x5a witness_lock(c635ce40,8,c0532609,bf,eb3828d4) at witness_lock+0x142 _mtx_lock_flags(c635ce40,0,c0532609,bf,c5e5) at _mtx_lock_flags+0x63 pcm_chnalloc(c21a9e00,1,c5e5,,8) at pcm_chnalloc+0x66 dsp_open(c03a6a50,7,2000,c6612780,c0534380) at dsp_open+0x12f spec_open(eb3829c8,eb382ae4,c0217796,eb3829c8,c03b3ae0) at spec_open+0x37d spec_vnoperate(eb3829c8,c03b3ae0,0,180,c6612780) at spec_vnoperate+0x18 vn_open_cred(eb382bd4,eb382cd4,0,c7575600,eb382cc0) at vn_open_cred+0x306 vn_open(eb382bd4,eb382cd4,0,295,eb382b20) at vn_open+0x29 kern_open(c6612780,888ceb0,0,7,0) at kern_open+0x197 open(c6612780,eb382d10,c0363f83,407,c6610c50) at open+0x30 syscall(875002f,2f,bfbf002f,6,0) at syscall+0x3d6 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x2932e273, esp = 0xbfa65abc, ebp = 0xbfa65ad8 --- Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
read/write errors with USB CF reader
Hi, (this is unrelated to my earlier post about the kernel panic.) when doing I/O to an IBM microdrive mounted via an USB CF reader, I get read/write errors about once an hour or so. Here's an example: dd if=/dev/zero of=/dev/da1 bs=512 count=32 dd: /dev/da1: Input/output error 1+0 records in 0+0 records out 0 bytes transferred in 0.905537 secs (0 bytes/sec) *** Error code 1 Relevant syslog excerpt: umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 2 umass0: Get Max Lun not supported (STALLED) da1 at umass-sim0 bus 0 target 0 lun 0 da1: Removable Direct Access SCSI-2 device da1: 1.000MB/s transfers da1: 1027MB (2104705 512 byte sectors: 255H 63S/T 131C) umass0: BBB reset failed, STALLED (da1:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da1:umass-sim0:0:0:0): AutoSense Failed umass0: BBB reset failed, STALLED (da1:umass-sim0:0:0:0): AutoSense Failed Retrying the failed command usually works (and the dd above was just an example, I've seen it happen with dump/restore, tar, or make.) Also, this may not be specific to -current, I think I saw it on -STABLE as well a while ago. The microdrive itself is fine, I also mount it with a CF PC-card adaptor, and have never seen an error then. Any clues? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
panic copying from USB drive
Hi, just got the following kernel panic when the USB hard drive I was copying from at the time ran out of batteries and powered off: umass0: ARCHOS ARCHOS USB2.0 (P4a), rev 2.00/11.01, addr 2 umass0: BBB reset failed, TIMEOUT da1 at umass-sim0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-0 device da1: 1.000MB/s transfers da1: 19077MB (39070080 512 byte sectors: 255H 63S/T 2432C) umass0: BBB reset failed, IOERROR umass0: BBB bulk-in clear stall failed, IOERROR umass0: BBB bulk-out clear stall failed, IOERROR umass0: at uhub2 port 2 (addr 2) disconnected (da1:umass-sim0:0:0:0): lost device umass0: detached Fatal trap 12: page fault while in kernel mode cpuid = 3; lapic.id = 0300 fault virtual address = 0x72 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02c6417 stack pointer = 0x10:0xe910c9bc frame pointer = 0x10:0xe910c9d4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 35 (usb1) kernel: type 12 trap, code=0 Stopped at vm_object_pip_add+0x37: movzwl 0x72(%esi),%eax db> trace vm_object_pip_add(0,1,1,e910ca98,e910ca88) at vm_object_pip_add+0x37 vm_fault(c082f000,deadc000,1,0,c63b60f0) at vm_fault+0x169 trap_pfault(e910cb80,0,deadc10a,51e,deadc10a) at trap_pfault+0x1b6 trap(18,c0370010,c0370010,0,caac6d00) at trap+0x3e5 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc01cddc7, esp = 0xe910cbc0, ebp = 0xe910cbfc --- device_get_nameunit(caac6800,caac6d00,6,0,caac683c) at device_get_nameunit+0x7 usb_transfer_complete(caac6800,2,caac6864,e910cc58) at usb_transfer_complete+0x133 uhci_abort_xfer(caac6800,6,e910cc68,c0180b39,caac6800) at uhci_abort_xfer+0x99 uhci_device_ctrl_abort(caac6800,ca771d80,e910cc74,c01807e1,ca771d80) at uhci_device_ctrl_abort+0x19 usbd_ar_pipe(ca771d80,e910cc88,c017f4a4,ca771d80,e910cca4) at usbd_ar_pipe+0x29 usbd_abort_pipe(ca771d80,e910cca4,c790e680,e910cca4,c017ffa8) at usbd_abort_pipe+0x11 usbd_kill_pipe(ca771d80,c63b00f0,c790e680,c62844c0,2) at usbd_kill_pipe+0x14 usb_free_device(c790e680,c6284500,11,0,0) at usb_free_device+0xa8 uhub_explore(c6284600,c6162820,e910cd0c,c017d7e8,c6162820) at uhub_explore+0x259 usb_discover(c6162820,0,5c,c03400f0,1770) at usb_discover+0x3a usb_event_thread(c6162820,e910cd48,c0345a83,35f,0) at usb_event_thread+0x68 fork_exit(c017d780,c6162820,e910cd48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xe910cd7c, ebp = 0 --- -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
an0: record length mismatch
Hi, just upgraded my laptop to yesterday's -current, and I keep seeing an0: record length mismatch -- expected 104, got 852 for Rid ff11 an0: record length mismatch -- expected 132, got 172 for Rid ff00 an0: record length mismatch -- expected 156, got 158 for Rid ff10 together with an0: device timeout root: FAIL an0 and then the machine freezes for about a second or so, then returns to normal. The card is a Cisco Aironet 350, running what I think is the latest firmware. Any ideas? Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
LOR: arp mutex/radix node head
On yesterday's -current: lock order reversal 1st 0xc03d2740 arp mutex (arp mutex) @ /usr/src/sys/netinet/if_ether.c:151 2nd 0xc64c6b7c radix node head (radix node head) @ /usr/src/sys/net/route.c:549 Will try to get a trace next time it happens. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: HEADSUP: CCD(4) hackery...
On 1/21/2003 12:25 PM, [EMAIL PROTECTED] wrote: Is there any way to revive my stripes, or are they toast? Your stripes should be unhurt. All you need is a new ccdconfig binary. Thanks! That did the trick. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: HEADSUP: CCD(4) hackery...
On 1/19/2003 7:03 AM, Poul-Henning Kamp wrote: CAUTION: Previously CCD would be different from all other disks in the system in that there were no "ccd0" device, only a "ccd0c" device. This is no longer so after this commit. If you access a ccd device through the "/dev/ccd0c" device _and_ have not actually put a BSD disklabel on the device, you will have to use the name "/dev/ccd0". If your CCD device contains a BSD disklabel there should be no difference. Of course I missed this heads-up before the upgrade... I just booted today's -current kernel in single-user mode to do an installworld, and when I do the usual "ccdconfig -C" (since my /usr is striped), I now get: # ccdconfig -C ccdconfig: open: /dev/ccd0c: No such file or directory My /etc/ccd.conf has: ccd0 127 0 /dev/da0s1e /dev/da1s1e Is there any way to revive my stripes, or are they toast? Thanks, Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: FreeBSD 5.0 and Dell notebooks
On 1/14/2003 10:50 PM, Nicholas Esborn wrote: I run CURRENT on a Dell Latitude C600 PP01L. I ran some tests to get more detailed information. During these tests, I was running: FreeBSD assisi 5.0-CURRENT FreeBSD 5.0-CURRENT #23: Sat Jan 11 17:19:32 PST 2003 nick@assisi:/usr/obj/usr/src/sys/ASSISI i386 I ran acpiconf -s [1-5] and noted the results: [snipped] Great summary! I see *exactly* the symptoms you are describing. acpiconf -s 4: The machine goes to a formal-looking text mode warning that there is no suspend-to-disk partition (which is true); With a partition created by Dell's make-suspend-partition floppy, I could suspend and resume with save-to-disk on 4.6. (I have since trashed the partition, because I needed its partition table slot.) So there is some hope this might work on -current also. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: FreeBSD on Dell Inspiron 8200 notebook
Vincent Poy wrote: On Tue, 14 Jan 2003, Lars Eggert wrote: >My Dell resumes from standby when I hit the power button briefly, i.e. >less than the 4 seconds or so that force a power off. Hmmm, not mines. When I hit the power button for like 1-3 seconds, I can see the lights change but the network portion atleast still isn't operating. The LEDs change on mine too, same as they do when I resume in Windows XP. (The screen stays off, this is the bug.) Not sure what you mean by "the network portion". Some network services don't react kindly to being suspended/resumed, but that's a different problem that can be worked around by stopping them before suspend, and restarting them on resume. I had some scripts that did this for 4.X, will port them to -current once I can resume... :-) I don't even know if the problem is FreeBSD related since on the DellTalk Forums at dell.com, people are having issues with suspend/resume even in WindowsXP where the machine will suspend but it will not wake up except in WindowsXP, the screen does go off but the screen will not go back on even when it resumes. FWIW, mine suspends and resumes perfectly in Windows XP. Be sure to run the latest Dell BIOS and device firmwares. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: FreeBSD on Dell Inspiron 8200 notebook
Vincent Poy wrote: On Tue, 14 Jan 2003, Lars Eggert wrote: >This has been discussed in the "ACPI video driver (for Dell Latitude >C640)" thread last August. The symptoms are actually a bit different: >The screens stays on on suspend, and goes black on resume. The machine >is still live after resume, and can be rebooted by typing blindly. I >believe this is a problem with certain ATI cards (mine, on a Latitude >C600, for example.) > >Someone (Mark Santcroos?) was going to fiddle with the ATI driver, but >nothing has ever materialized that I'm aware off. > >This is *the* key issue that makes -current on these Dell laptops >unpleasant, everything else has been working great for months. Actually, I have a NVidia GeForce4Go 440 w/64 Megs so the problem might not be related to the video card itself since the IBM ThinkPad A31P uses the same video cards and the problem doesn't exist. How did you manage to even get the machine to resume since I've tried hitting the escape key and even blindly typing but the machine is still suspended with the LCD on as I can't even ping the machine from the network and the only way out is to hold the power button down for 8 seconds and then power back on. My Dell resumes from standby when I hit the power button briefly, i.e. less than the 4 seconds or so that force a power off. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: FreeBSD on Dell Inspiron 8200 notebook
Nate Lawson wrote: On Tue, 14 Jan 2003, Lars Eggert wrote: >Vincent Poy wrote: > > >> Just curious but does the LCD stay on when the machine suspends >>since on mines, the last thing displayed will remain there until I hold >>the power button down to manually shut the machine off and then the power >>on where it does the fsck's and FreeBSD boots again. > >This has been discussed in the "ACPI video driver (for Dell Latitude >C640)" thread last August. The symptoms are actually a bit different: >The screens stays on on suspend, and goes black on resume. The machine >is still live after resume, and can be rebooted by typing blindly. I >believe this is a problem with certain ATI cards (mine, on a Latitude >C600, for example.) > >Someone (Mark Santcroos?) was going to fiddle with the ATI driver, but >nothing has ever materialized that I'm aware off. > >This is *the* key issue that makes -current on these Dell laptops >unpleasant, everything else has been working great for months. Have you tried: options SC_NO_SUSPEND_VTYSWITCH It's probably not this but worth looking at. Thanks for the tip, but it doesn't change anything unfortunately. This is pretty strange, it looks like the machine suspends before the display sleep code has finished executing, and when it resumes, it executes the rest, and turns off the display... Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: FreeBSD on Dell Inspiron 8200 notebook
Vincent Poy wrote: Just curious but does the LCD stay on when the machine suspends since on mines, the last thing displayed will remain there until I hold the power button down to manually shut the machine off and then the power on where it does the fsck's and FreeBSD boots again. This has been discussed in the "ACPI video driver (for Dell Latitude C640)" thread last August. The symptoms are actually a bit different: The screens stays on on suspend, and goes black on resume. The machine is still live after resume, and can be rebooted by typing blindly. I believe this is a problem with certain ATI cards (mine, on a Latitude C600, for example.) Someone (Mark Santcroos?) was going to fiddle with the ATI driver, but nothing has ever materialized that I'm aware off. This is *the* key issue that makes -current on these Dell laptops unpleasant, everything else has been working great for months. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: VOP_SPECSTRATEGY on non-VCHR
[EMAIL PROTECTED] wrote: In message <[EMAIL PROTECTED]>, Lars Eggert writes: >just got this on today's -current, when accessing a mounted NTFS partition: > >VOP_SPECSTRATEGY on non-VCHR >: 0xc6d73c34: tag ntfs, type VREG, usecount 3, writecount 0, refcount 0, >flags (VV_OBJBUF), lock type ntfs: SHARED (count 1) Can you try this patch ? The patch fixes things in the sense that I now longer see the message. Thanks! Index: vnode_pager.c === RCS file: /home/ncvs/src/sys/vm/vnode_pager.c,v retrieving revision 1.167 diff -u -r1.167 vnode_pager.c --- vnode_pager.c 5 Jan 2003 20:32:03 - 1.167 +++ vnode_pager.c 12 Jan 2003 10:21:08 - @@ -823,7 +823,10 @@ cnt.v_vnodepgsin += count; /* do the input */ - VOP_SPECSTRATEGY(bp->b_vp, bp); + if (dp->v_type == VCHR) + VOP_SPECSTRATEGY(bp->b_vp, bp); + else + VOP_STRATEGY(bp->b_vp, bp); s = splvm(); /* we definitely need to be at splvm here */ Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
VOP_SPECSTRATEGY on non-VCHR
Hi, just got this on today's -current, when accessing a mounted NTFS partition: VOP_SPECSTRATEGY on non-VCHR : 0xc6d73c34: tag ntfs, type VREG, usecount 3, writecount 0, refcount 0, flags (VV_OBJBUF), lock type ntfs: SHARED (count 1) vop_nospecstrategy(eb4d0afc,eb4d0b3c,c02cf91d,eb4d0afc,d28eed88) at vop_nospecstrategy+0x5b vop_defaultop(eb4d0afc,d28eed88,dbbab000,eb4d0af4,0) at vop_defaultop+0x18 vnode_pager_generic_getpages(c6d73c34,eb4d0c6c,1000,0,eb4d0b60) at vnode_pager_generic_getpages+0x41d vop_stdgetpages(eb4d0b78,eb4d0b9c,c02cf4e7,eb4d0b78,1) at vop_stdgetpages+0x29 vop_defaultop(eb4d0b78,1,c035c4ec,273,c0368280) at vop_defaultop+0x18 vnode_pager_getpages(c6cff688,eb4d0c6c,1,0,eb4d0c1c) at vnode_pager_getpages+0x77 vm_fault(c21ba104,28181000,1,0,c6a177e0) at vm_fault+0xfcf trap_pfault(eb4d0d48,1,28181000,297,28181000) at trap_pfault+0xd2 trap(2f,2f,2f,8067000,0) at trap+0x20c calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x2807e9e5, esp = 0xbfbffa54, ebp = 0xbfbffa58 --- Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Cordless Keyboard + Mouse
Daniel O'Connor wrote: Hmm odd.. I don't see why vidcontrol wouldn't work.. Does it print any error messages? Do you use a serial console? vidcontrol fails to init the mouse then. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Two LORs.
Juli Mallett wrote: The first is new to me (I've lagged behind for a while) and the second is something I've reported to Cameron, but continually get, so I thought I'd post again. lock order reversal 1st 0xc12c9b18 process lock (process lock) @ ../../../kern/kern_descrip.c:2099 2nd 0xc12d3d34 filedesc structure (filedesc structure) @ ../../../kern/kern_descrip.c:2106 Same here, with today's -current. Hadn't updated since mid-December, just noticed it. LOR is reproducible, always happens early during boot: SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da0s1a lock order reversal 1st 0xc65d53f8 process lock (process lock) @ /usr/src/sys/kern/kern_descrip.c:2099 2nd 0xc655fa34 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:2106 savecore: no dumps found Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Renumber IPPROTO_DIVERT
Lars Eggert wrote: Bill Fenner wrote: > >Was /etc/protocols maybe simply forgotten in the 10/29/02 change? > > Yes. Does changing it to 258 work? it makes the syslog message go away and the socket opens. I haven't tested yet if diverting works, need to port some other pieces first. I'll let you know later (today, hopefully.) Yes, changing 254 -> 258 in /etc/protocols works. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: Renumber IPPROTO_DIVERT
Bill Fenner wrote: >Was /etc/protocols maybe simply forgotten in the 10/29/02 change? Yes. Does changing it to 258 work? it makes the syslog message go away and the socket opens. I haven't tested yet if diverting works, need to port some other pieces first. I'll let you know later (today, hopefully.) Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature