Re: Replacement for intel ISP1100 on FBSD 4.5?
> where are you getting the 2U half-depth cases from? www.rackable.com (who is actually doing all the dirty work of having to touch PC hardware at all, and delivered to us finished cabinets of computers). I believe that they are manufacturing their own cases for this, though it is possible that they are outsourced. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: pcmcia insert/remove/insert on boot?
In message: <[EMAIL PROTECTED]> Tim Kellers <[EMAIL PROTECTED]> writes: : I see that same message on the Dell latitude I'm using --with both the Dell : TrueMobile and the Orinoco Wavelan cards (both gold and silver). Apparently : is cause no trouble (that I've seen). If it didn't show up in red on my : console, I'd probably not have noticed it until I read a dmesg As far as I can tell, it is a benign bug for most people. I think that it comes from not masking a certain type of interrupt while the card is becoming ready, as the standard/mindshare books recommend. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Replacement for intel ISP1100 on FBSD 4.5?
On Sat, Mar 16, 2002 at 11:44:54AM -0800, Jason Fesler wrote: > If you don't mind putting your own boxes together (or going through a > reseller that does), I"m finding the SBC2 Intel boards (aka, Coos Bay) are > working fairly well. F2 does work over serial; comes with dual nic built > in; running headless. Our configuration is 2U but half-depth. where are you getting the 2U half-depth cases from? Thanks, Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: pcmcia insert/remove/insert on boot?
I see that same message on the Dell latitude I'm using --with both the Dell TrueMobile and the Orinoco Wavelan cards (both gold and silver). Apparently is cause no trouble (that I've seen). If it didn't show up in red on my console, I'd probably not have noticed it until I read a dmesg Tim Kellers On Thursday 21 March 2002 10:44 pm, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > > Alan Clegg <[EMAIL PROTECTED]> writes: > : Something that I'm noticing now that I'm not sure I saw in the past: > : > : ad0: 19077MB [38760/16/63] at ata0-master UDMA33 > : Mounting root from ufs:/dev/ad0s2a > : pccard: card inserted, slot 1 > : pccard: card removed, slot 1 > : pccard: card inserted, slot 1 > : wi0: at port 0x240-0x27f irq 11 slot 1 on pccard1 > : wi0: 802.11 address: 00:02:2d:0d:66:cc > : wi0: using Lucent chip or unknown chip > : > : Note the insert/remove/insert sequence ... > : > : Anyone else seen this or care? > > H. I've seen this myself, but haven't had enough time to look > into it. :-( > > Warner > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Machine Lockups on 4.5-RELEASE
I have an AMD 486 DX-100 machine that has run flawlessly since 4.0-RELEASE. Although slow, I build custom kernels, and use ports to build and install software. The software on this machine is minimal as I use it for my firewall and to serve DHCP requests. Here is the list of installed ports: blacksheep# pkg_info autoconf213-2.13.000227_1 Automatically configure source code on many Un*x platforms dhcping-1.1 Send DHCP request to DHCP server for monitoring purposes gettext-0.10.35_1 GNU gettext package gmake-3.79.1GNU version of 'make' utility isakmpd-20020104OpenBSD IKE daemon isc-dhcp3-3.0.1.r6 ISC Dynamic Host Configuration Protocol client and server c libtool-1.3.4_2 Generic shared library support script m4-1.4_1GNU's m4 mpd-3.6 Multi-link PPP daemon based on netgraph(4) pkg_tarup-1.2_3 Generates binary package from installed package portupgrade-20020227 Very powerful FreeBSD ports/packages upgrading tool and mor ruby-1.6.7.2002.03.13 An object-oriented interpreted scripting language ruby-bdb1-0.1.6 Ruby interface to Berkeley DB revision 1.8x with full featu ruby-fnmatch-1.1b_1 A Ruby module which provides File::fnmatch and File::FNM_* ruby-optparse-0.8.6 Yet another command line option parser for Ruby sharity-light-1.2 An userland smbfs --- SMB to NFS protocols converter snort-1.8.3 Lightweight network intrusion detection system I've had no problems until upgrading from 4.4-RELEASE to 4.5-RELEASE. Since the upgrade, my machine locks up occasionally when under heavy load, doing things like compiling or updating to ports database. The only thing I can do at this point is power off/on the machine. I know at first this appears hardware related but I don't suspect it is because it started right after the upgrade. Is there anything that happened between 4.4 & 4.5 that could account for this? If so, has it been fixed in -STABLE? If it helps, I'd be willing to revert to 4.4-RELEASE and see if the problem persists. Thanks for any input, Drew dmesg output follows: blacksheep# dmesg Copyright (c) 1992-2002 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.5-RELEASE #3: Tue Jan 29 21:45:21 PST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BLACKSHEEP Timecounter "i8254" frequency 1193852 Hz CPU: AMD Enhanced Am486DX4 Write-Through (486-class CPU) Origin = "AuthenticAMD" Id = 0x484 Stepping = 4 Features=0x1 real memory = 50331648 (49152K bytes) config> di sn0 config> di lnc0 config> di ie0 config> di cs0 config> en ed0 config> po ed0 0x240 config> ir ed0 9 config> iom ed0 0xd8000 config> f ed0 0 config> en ed1 config> po ed1 0x260 config> ir ed1 11 config> iom ed1 0xd config> f ed1 0 config> q avail memory = 45703168 (44632K bytes) Preloaded elf kernel "kernel" at 0xc034f000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc034f09c. netsmb_dev: loaded md0: Malloc disk npx0: on motherboard npx0: INT 16 interface isa0: on motherboard isa0: too many dependant configs (8) orm0: at iomem 0xc-0xc7fff on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fd1: <1200-KB 5.25" drive> on fdc0 drive 1 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: at port 0x60,0x64 on isa0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ed0 at port 0x240-0x25f iomem 0xd8000 irq 9 drq 0 on isa0 ed0: address 00:40:05:66:b2:55, type NE2000 (16 bit) ed1 at port 0x260-0x27f iomem 0xd irq 11 drq 0 on isa0 ed1: address 00:40:05:66:b2:52, type NE2000 (16 bit) IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, unlimited logging IPsec: Initialized Security Association Processing. ad0: 814MB [1654/16/63] at ata0-master BIOSPIO ad1: 814MB [1654/16/63] at ata0-slave BIOSPIO ad2: 4103MB [8894/15/63] at ata1-master BIOSPIO acd0: CDROM at ata1-slave using BIOSPIO Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
lib crypt/descrypt/scrypt
When did a single libcrypt replace the separate libdescrypt and libscrypt libraries in -STABLE? My reason for asking... I've been having some odd errors[1] when profiling, and finally traced it down to a stale libdescrypt.so.2 library remaining in /usr/lib. Is there any harm in removing the descrypt and scrypt libraries, and can there be something in UPDATING letting others know that these libraries changed and may need to be removed? I run FreeBSD botbay.net 4.5-STABLE FreeBSD 4.5-STABLE #0: Fri Mar 8 10:21:33 EST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KABEL i386 and the system has been updated from source since 3.1-R [1] wcampbel@botbay (Stats): bin/mkpasswd /usr/libexec/ld-elf.so.1: /usr/lib/libcrypt.so.2: Undefined symbol "_CurrentRuneLocale" wcampbel@botbay (Stats): ls -l /usr/lib/libcrypt.so.2 -r--r--r-- 1 root wheel 28588 8 mar 11:59 /usr/lib/libcrypt.so.2 wcampbel@botbay (Stats): ls -l /usr/lib/libdescrypt.so.2 -r--r--r-- 1 root wheel 11680 1 mai 2001 /usr/lib/libdescrypt.so.2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.5r -> 4.5s panic: breaks raid array
Actually, I just had happen something similar. In this case, I just rebuilt the box with an SMP kernel, and when I rebooted, no RAID 1 e.g. before Mar 22 14:49:16 raidtest /kernel: twe0: <3ware Storage Controller> port 0xb000-0xb00f irq 15 at device 9.0 on pci0 Mar 22 14:49:16 raidtest /kernel: twe0: 2 ports, Firmware FE6X 1.02.28.053, BIOS BE6X 1.07.02.005 Mar 22 14:49:16 raidtest /kernel: atapci1: port 0x9400-0x94ff,0x9800-0x9803,0xa000-0xa007,0xa 400-0xa403,0xa800-0xa807 irq 12 at device 10.0 on pci0 Mar 22 14:49:16 raidtest /kernel: ata2: at 0xa800 on atapci1 Mar 22 14:49:16 raidtest /kernel: ata3: at 0xa000 on atapci1 Mar 22 14:49:16 raidtest /kernel: atapci2: port 0x7800-0x78ff,0x8000-0x8003,0x8400-0x8407,0x8 800-0x8803,0x9000-0x9007 irq 12 at device 10.1 on pci0 Mar 22 14:49:16 raidtest /kernel: ata4: at 0x9000 on atapci2 Mar 22 14:49:16 raidtest /kernel: ata5: at 0x8400 on atapci2 Mar 22 14:49:16 raidtest /kernel: ar0: 38166MB [4865/255/63] status: READY subdisks: Mar 22 14:49:16 raidtest /kernel: 0 READY ad8: 38166MB [77545/16/63] at ata4-master UDMA100 Mar 22 14:49:16 raidtest /kernel: 1 READY ad10: 38166MB [77545/16/63] at ata5-master UDMA100 Mar 22 14:49:16 raidtest /kernel: twed0: on twe0 Mar 22 14:49:16 raidtest /kernel: twed0: 38165MB (78163312 sectors) and after no ar0 Mar 23 08:49:42 raidtest /kernel: APIC_IO: Testing 8254 interrupt delivery Mar 23 08:49:42 raidtest /kernel: APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Mar 23 08:49:42 raidtest /kernel: SMP: AP CPU #1 Launched! Mar 23 08:49:42 raidtest /kernel: ad0: 19541MB [39703/16/63] at ata0-master UDMA33 Mar 23 08:49:42 raidtest /kernel: ad8: 38166MB [77545/16/63] at ata4-master UDMA100 Mar 23 08:49:42 raidtest /kernel: ad10: 38166MB [77545/16/63] at ata5-master UDMA100 Mar 23 08:49:42 raidtest /kernel: twed0: on twe0 Mar 23 08:49:42 raidtest /kernel: twed0: 38165MB (78163312 sectors) Mar 23 08:49:42 raidtest /kernel: Mounting root from ufs:/dev/ad0s1a I am not in front of the box so I wont be able to check what the card thinks until tomorrow. ---Mike At 08:24 PM 3/22/2002 -0800, Kris Kennaway wrote: >On Fri, Mar 22, 2002 at 06:07:47PM -0800, pan wrote: > > > Installed fBSD 4.5-release from CD - no problem > > cvsup to 4.5-stable (March 22 2002) went well > > through mergemaster but failed on subsequent reboot > >Sounds like you didn't upgrade properly -- are you sure you rebuilt >both kernel and world according to the instructions in the handbook? > >Kris Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Network slowdowns...
Hiya I've recently been experiencing slowdowns on my server's outgoing network port, which occur after half a day to a day after the last reboot. To briefly summarise: I have an old K6-2 300 acting as a gateway and firewall between my internal network and my DSL connection. It was working fine until a few days ago when I upgraded the harddrive to a 60GB 120GXP, upgraded to the latest -stable, and switched off the DEFAULT_TO_ACCEPT firewall option. Every thing is fine until the system starts to play up, at which point traffic through the server->DSL box starts to become really slow - when ssh-ing in from a remote machine, characters can take several seconds to appear - all other services are affected in the same way. There don't seem to be any clues in the log files, either. Internal networking (fxp0) always works fine, and rebooting always fixes the problem. Here is the dmesg: Copyright (c) 1992-2002 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.5-STABLE #1: Thu Mar 21 12:13:11 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DOOKIE Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 298816447 Hz CPU: AMD-K6(tm) 3D processor (298.82-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping = 0 Features=0x8001bf AMD Features=0x8800 real memory = 67108864 (65536K bytes) avail memory = 62230528 (60772K bytes) Preloaded elf kernel "kernel" at 0xc0315000. md0: Malloc disk Using $PIR table, 5 entries at 0xc00fdae0 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: <3Dfx Voodoo 3 graphics accelerator> at 0.0 irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xc000-0xc00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 chip1: at device 7.3 on pci0 fxp0: port 0xc400-0xc41f mem 0xed00-0xed0f,0xed12-0xed120fff irq 10 at device 9.0 on pci0 fxp0: Ethernet address 00:a0:c9:4b:f8:33 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xc800-0xc83f irq 9 at device 10.0 on pci0 xl0: Ethernet address: 00:60:08:4f:f6:f8 miibus1: on xl0 nsphy0: on miibus1 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto atapci1: port 0xdc00-0xdc3f,0xd800-0xd803,0xd400-0xd407,0xd000-0xd003,0xcc00-0xcc07 mem 0xed10-0xed11 irq 12 at device 11.0 on pci0 ata2: at 0xcc00 on atapci1 ata3: at 0xd400 on atapci1 orm0: at iomem 0xc-0xc7fff,0xc8000-0xc97ff on isa0 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to deny, logging limited to 10 packets/entry by default IP Filter: v3.4.20 initialized. Default = pass all, Logging = disabled ad4: 58644MB [119150/16/63] at ata2-master UDMA66 acd0: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd0: MODE_SENSE_BIG DONEDRQ acd0: MODE_SENSE_BIG - ABORTED COMMAND asc=0x4e ascq=0x00 error=0x00 acd0: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd0: MODE_SENSE_BIG DONEDRQ acd0: MODE_SENSE_BIG - ABORTED COMMAND asc=0x4e ascq=0x00 error=0x00 acd0: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd0: MODE_SENSE_BIG DONEDRQ acd0: MODE_SENSE_BIG - ABORTED COMMAND asc=0x4e ascq=0x00 error=0x00 acd0: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd0: MODE_SENSE_BIG DONEDRQ acd0: MODE_SENSE_BIG - ABORTED COMMAND asc=0x4e ascq=0x00 error=0x00 acd0: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd0: MODE_SENSE_BIG DONEDRQ acd0: MODE_SENSE_BIG - ABORTED COMMAND asc=0x4e ascq=0x00 error=0x00 acd0: CDROM at ata1-master PIO3 Mounting root from ufs:/dev/ad4s1a I've always had the "MODE_SENSE_BIG - ABORTED COMMAND" bits; the harddrive is on a PCI ATA66 card. Here are the relevent bits of my firewall script (IPs changed to protect the guilty 8^) [Ss][Ii][Mm][Pp][Ll][Ee]) # This is a prototype setup for a simple firewall. Configure this # machine as a named server and ntp server, and point all the machines # on the inside at this machine for those services. # set these to your outside interface network and netmask and ip oif="xl0" onet="213.105.71.0" #onet="192.0.2.0" omask="255.255.255.0" oip="213.105.71.121" #oip="192.0.2.1" # set these to your inside interface network and net
Re: ATA-tags broken on STABLE (long!)
Well, same (kernel-panic with hw.ata.tags="1") for me:
...
atapci0: port 0xd000-0xd00f at device \
7.1 on pci0
atapci0: Correcting VIA config for southbridge data corruption bug
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
...
ad0: 43979MB [89355/16/63] at ata0-master UDMA100
I fired up 'gdb' according to the developers handbook on the
vmcore-file. Here's the log of the session:
root@mscu - /usr/obj/usr/src/sys/MSCU
502 # gdb -k kernel.debug /var/crash/vmcore.5
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD at phsyical address 0x004e2000
initial pcb at physical address 0x0034c9a0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x70
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0185730
stack pointer = 0x10:0xc030585c
frame pointer = 0x10:0xc0305880
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 = Idle
interrupt mask = net tty bio cam
trap number = 12
panic: page fault
syncing disks... 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
giving up on 1 buffers
Uptime: 16s
dumping to dev #da/0x20001, offset 262272
dump 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240
239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222
221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204
203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186
185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168
167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150
149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132
131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114
113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95
94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71
70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47
46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23
22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1 0xc01826ff in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:316
#2 0xc0182b24 in poweroff_wait (junk=0xc02faccc, howto=-1070618641)
at /usr/src/sys/kern/kern_shutdown.c:595
#3 0xc02a4936 in trap_fatal (frame=0xc030581c, eva=112)
at /usr/src/sys/i386/i386/trap.c:966
#4 0xc02a4609 in trap_pfault (frame=0xc030581c, usermode=0, eva=112)
at /usr/src/sys/i386/i386/trap.c:859
#5 0xc02a41f3 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = 0, tf_esi = -1055602944, tf_ebp = -1070573440,
tf_isp = -1070573496, tf_ebx = 0, tf_edx = 1014, tf_ecx = -1055641088,
tf_eax = 4194304, tf_trapno = 12, tf_err = 0, tf_eip = -1072146640,
tf_cs = 8, tf_eflags = 66118, tf_esp = 496, tf_ss = -1055602900})
at /usr/src/sys/i386/i386/trap.c:458
#6 0xc0185730 in tsleep (ident=0xc114c700, priority=16,
wmesg=0xc02c5c46 "atacmd", timo=1000) at
/usr/src/sys/kern/kern_synch.c:436
#7 0xc0136b9d in ata_command
(atadev=0xc114c72c, command=236 'ì', lba=0, count=0, feature=0,
flags=2) at /usr/src/sys/dev/ata/ata-all.c:1048
#8 0xc01356b7 in ata_getparam (atadev=0xc114c72c, command=236)
at /usr/src/sys/dev/ata/ata-all.c:428
#9 0xc013637e in ata_reinit (ch=0xc114c700)
at /usr/src/sys/dev/ata/ata-all.c:845
#10 0xc013e2ba in ad_timeout (request=0xc11d2600)
at /usr/src/sys/dev/ata/ata-disk.c:893
#11 0xc018858d in softclock () at /usr/src/sys/kern/kern_timeout.c:131
(kgdb) up 7
#7 0xc0136b9d in ata_command (atadev=0xc114c72c, command=236 'ì',
lba=0, count=0, feature=0, flags=2) at
/usr/src/sys/dev/ata/ata-all.c:1048
(kgdb) list
1043
1044/* enable interrupt */
1045if (atadev->channel->flags & ATA_QUEUED)
1046ATA_OUTB(atadev->channel->r_altio, ATA_ALTSTAT, ATA_A_4BIT);
1047
1048if (tsleep((caddr_t)atadev->channel, PRIBIO, "atacmd", 10 * hz))
{
1049ata_prtdev(atadev, "timeout waiting for interrupt\n");
1050atadev->channel->active &= ~ATA_WAIT_INTR;
1051error = -1;
1052}
(kgdb) up
#8 0
Re: MFC of ATA driver from -current finished, please test..
On Mon, 18 Mar 2002, Søren Schmidt wrote: > Please let me know asap if you encounter any (new) problems with the > ATA driver after this commit. I have a Digital Celebris 6200 (PPro 200MHz) with an Orinoco isa<->pcmcia bridge and an Orinoco 802.11b card. Using STABLE before the new ATA driver was committed the ata controller was probed like this: atapci0: port 0xecd0-0xecdf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0-master: DMA limited to UDMA33, non-ATA66 compliant cable ad0: 76319MB [155061/16/63] at ata0-master WDMA2 acd0: CDROM at ata0-slave using PIO3 Usinng the new driver it is probed like this: atapci0: port 0xecd0-0xecdf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 76319MB [155061/16/63] at ata0-master WDMA2 acd0: CDROM at ata0-slave PIO3 I have no devices on ata1 and before the new ata driver I was not even aware that it existed. Up until now I have been happily using irq 15 for wi0 (the Orinoco card). With the new driver probing ata1 at irq15, pccardd will not use the wi card, complaining "Failed to allocate IRQ for Lucent Technologies". If I run "atacontrol detach 1", then pccardd will allocate IRQ 15 for wi0 and everything works as before. Now I have added "atacontrol detach 1" in /etc/rc.pccard right before the "pccardc pccardmem" command, and the system boots up with wi0 and everything works fine. My questions are, 1) Is this the way it's supposed to work? 2) Is there any way to disable probing of ata1 at boot time? (My bios setup did not seem to provide any explicit way of disabling it) 3) Does my workaround of running "atacontrol detach 1" from rc.pccard seem like a reasonable workaround? 4) If the answer to 2 is no and the answer to 3 is yes, should this be made configurable via a variable in rc.conf? Thanks, -- Tod McQuillin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
