lock order reversal messages?
Hi Just got some while colleague used the bridge segment behind fxp1 interface. Copyright (c) 1992-2000 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.0-CURRENT #0: Tue Nov 21 15:22:26 EET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/Myhakas.SMP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (501.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 268435456 (262144K bytes) avail memory = 257351680 (251320K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc03ba000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc03ba09c. Pentium Pro MTRR support enabled VESA: v2.0, 32768k memory, flags:0x1, mode table:0xc00c6954 (c0006954) VESA: Matrox Graphics Inc. npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443GX host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: Intel 82443GX (440 GX) PCI-PCI (AGP) bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: Matrox MGA G400 AGP graphics accelerator at 0.0 irq 16 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2 Timecounter "PIIX" frequency 3579545 Hz pci0: Intel 82371AB Power management controller at 7.3 ahc0: Adaptec aic7896/97 Ultra2 SCSI adapter port 0xe400-0xe4ff mem 0xfebfc000-0xfebfcfff irq 16 at device 11.0 on pci0 aic7896/97: Wide Channel A, SCSI Id=7, 32/255 SCBs ahc1: Adaptec aic7896/97 Ultra2 SCSI adapter port 0xe800-0xe8ff mem 0xfebff000-0xfebf irq 16 at device 11.1 on pci0 aic7896/97: Wide Channel B, SCSI Id=7, 32/255 SCBs pcm0: AudioPCI ES1371 port 0xed80-0xedbf irq 18 at device 12.0 on pci0 fxp0: Intel Pro 10/100B/100+ Ethernet port 0xee80-0xeebf mem 0xfe80-0xfe8f,0xfebfd000-0xfebfdfff irq 19 at device 13.0 on pci0 fxp0: Ethernet address 00:e0:81:10:50:32 fxp1: Intel Pro 10/100B/100+ Ethernet port 0xef00-0xef3f mem 0xfea0-0xfeaf,0xfebfe000-0xfebfefff irq 17 at device 15.0 on pci0 fxp1: Ethernet address 00:90:27:54:57:26 ed0: NE2000 PCI Ethernet (RealTek 8029) port 0xef80-0xef9f irq 18 at device 18.0 on pci0 ed0: address 00:e0:29:6d:14:19, type NE2000 (16 bit) atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 sc0: System console at flags 0x100 on isa0 sc0: VGA 9 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0f13 can't assign resources APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 BRIDGE 990810, have 4 interfaces -- index 1 type 6 phy 0 addrl 6 addr 00.e0.81.10.50.32 -- index 2 type 6 phy 0 addrl 6 addr 00.90.27.54.57.26 -- index 3 type 6 phy 0 addrl 6 addr 00.e0.29.6d.14.19 ad0: 14649MB IBM-DTLA-307015 [29765/16/63] at ata0-master tagged UDMA33 ad1: 35772MB IBM-DPTA-353750 [72680/16/63] at ata1-master tagged UDMA33 Waiting 5 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s1a da0 at ahc0 bus 0 target 1 lun 0 da0: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) da1 at ahc0 bus 0 target 2 lun 0 da1: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 31, 16bit), Tagged Queueing Enabled da1: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) da2 at ahc1 bus 0 target 1 lun 0 da2: QUANTUM FIREBALL_TM3200S 300X Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da2: 3067MB (6281856 512 byte sectors: 255H 63S/T 391C) cd0 at ahc1 bus 0 target 0 lun 0 cd0: TOSHIBA CD-ROM XM-6201TA 1030 Removable CD-ROM
Re: Problem Compiling Kernel
"Brune, Michael" wrote: I CVSup'ed the sources today, built and installed world and everything was fine. When I tried to compile the kernel, I recieve this error when I do the 'make depend' ./aicasm -nostdinc -I- -I. -I../../ -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -I../../cam/scsi -I../../dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h ../../dev/aic7xxx/aic7xxx.seq ./aicasm: Stopped at file ../../dev/aic7xxx/aic7xxx.seq, line 81 - syntax error ./aicasm: Removing aic7xxx_seq.h due to error ./aicasm: Removing aic7xxx_reg.h due to error *** Error code 65 I looked at the file aic7xxx.seq on line 81, but I did not see any errors. This is on a Dell Latitude 600 PIII. Please let me know if anyone has a suggestion or needs more information. Thanks in advance! Corey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Please ignore this email. The problem wan mine... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
new zero copy sockets and NFS snapshot
[ -arch and -current BCC'ed for wider coverage, please direct followups to -net and/or me ] I have put a new copy of the zero copy sockets and NFS patches, against -current as of early November 20th, 2000, here: http://people.FreeBSD.ORG/~ken/zero_copy/ Questions, comments and feedback are welcome. Besides being generated against a newer version of -current, the following things have changed in the new patches posted above: - The fix to the "localhost panic" problem has been revamped. We now use a new external mbuf type, EXT_DISPOSABLE, to indicate that the external mbuf payload may be page-flipped or otherwise discarded. Instead of attempting to page flip any pages that meet the size and alignment criteria, we now only page flip external mbufs marked as disposable. (Thanks to Drew Gallatin for suggesting this approach.) - The decision process on when to use vm_uiomove() versus vm_pgmoveco() in uiomoveco() has been revamped somewhat. We no longer panic in any case. Anything that isn't handled by vm_pgmoveco() (according to the page flip criteria described above) is passed to vm_uiomove(). - uiomoveco() has been reorganized somewhat, with some of the functionality split out into a subfunction. There are no known problems with the code. If anyone wants to challenge that, I'll gladly accept bug reports, code comments, etc. :) For those of you who missed the previous messages about this code (that went out to -net, -arch and -current), here's a quick list of what is included in the code: - Zero copy send and receive code, written by Drew Gallatin [EMAIL PROTECTED]. - Zero copy NFS code, written by Drew Gallatin. - Header splitting firmware for Alteon's Tigon II boards (written by me), based on version 12.4.11 of their firmware. This is used in combination with the zero copy receive code to guarantee that the payload of TCP or UDP packet is placed into a page-aligned buffer. - Alteon firmware debugging ioctls and supporting routines for the Tigon driver (also written by me). This will help anyone who is doing firmware development under FreeBSD for the Tigon boards. The Alteon header splitting and debugging code was written for Pluto Technologies (www.plutotech.com), which kindly agreed to let me release the code. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current scheduler strangeness
(just a little extra info) Scheduler issues have been present since at least 20001112-current. I installed the snapshot as my first venture into the current tree. Mp3 skippage and loopage was very bad. The box in question is an amd k6-2 300 (lower than average in this list, i gather). Mp3 decoding is only a 15-18% processor load, yet -current would skip jump even while doing nothing else. a note on "pcm0: hwptr went backwards XXX - XXX" I did not get these in 4.0-release. (or at least didn't notice them in six months..) I got a lot of these in -current. I've gotten two of these so far since reinstalling 4.1.1-release a few days ago. (i think they coincided with a load of mp3 playing, two compiles, a mv between hds on my dma-crippled ata controller (this is heavy for me my 300)) (sorry if this thread is outdated, i've been following -digest til now) -- chuck [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
The other interface will be an enumerative interface where you can get a callback for each CIS entry. These will be bus method based so that they will be the same between 16-bit and 32 bit code. I don't think the enumerative interface should be callback based. I'd rather have something that facilitates walking the CIS that can be used at anytime. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes: : The other interface will be an enumerative interface where you can get : a callback for each CIS entry. These will be bus method based so that : they will be the same between 16-bit and 32 bit code. : : I don't think the enumerative interface should be callback based. I'd : rather have something that facilitates walking the CIS that can be used : at anytime. That's what I mean. You call this, and it will remap the CIS (if it has been unmapped), walk it for you and pass you a pointer to each CIS entry one at a time to the function you specify. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Clock Strangeness in UP Kernel
I have a high clock drift rate. The problem is in selecting the timecounter, at least on my machine. Both the TSC and the i8254 timecounters are checked and, since, I believe, TSC is last, TSC is the timecounter the kernel uses. TSC is a horrible timer, at least on my machine. i8254 is not perfect, but several orders of magnitude better, at least with FreeBSD. # sysctl -a ... kern.timecounter.hardware: TSC ... # sysctl -w kern.timecounter.hardware=i8264 fixes the clock drift. Now, it is less than 2 seconds per 4 hours. And, that is well within the range ntp can satisfactorily correct for. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
That's what I mean. You call this, and it will remap the CIS (if it has been unmapped), walk it for you and pass you a pointer to each CIS entry one at a time to the function you specify. Warner I'd rather have a seek/read interface than have a callback. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No console on AlphaServer 2000 4/233 4.2-RC2
Hi, Console, console, where's the console? We are attempting to use FreeBSD 4.2-RC2 on an AlphaServer 2000 4/233 and are running into trouble with the console device. When we boot from the CD, it comes up to the boot prompt on the console where we tell it to boot from the cd device. The cd then boots up to the following: /stand/sysinstall running as init on serial console These are the predefined terminal types available to sysinstall when running stand-alone. Please choose the closest match for your particular terminal. 1 .. Standard ANSI terminal. 2 .. VT100 or compatible terminal. 3 .. FreeBSD system console (color) 4 .. FreeBSD system console (monochrome) 5 .. xterm terminal emulator Your choice: (1-5) At this point, no keyboard input is accepted. We then successfully installed onto an AlphaServer 1000 and moved the disks to the 2000. At this point the console is still useless, but we can telnet into the machine and use it... I've included the dmesg output below. Note, on the console after boot, but right before the useless login prompt: Cannot open /dev/ttyv0: not such device or address and from ls: %ls -al /dev/ttyv0 crw--- 1 root wheel 12, 0 Nov 21 10:02 /dev/ttyv0 So, it seems getty can't open the virtual terminal devices. A ps -aux right after boot: PID PPID UID %CPU %MEM STAT TIME COMMAND 0 0 0 0.0 0.0 DLs0:00.00 (swapper) 1 0 0 0.0 0.2 ILs0:00.03 (init) 2 0 0 0.0 0.0 DL 0:00.00 (pagedaemon) 3 0 0 0.0 0.0 DL 0:00.00 (vmdaemon) 4 0 0 0.0 0.0 DL 0:00.00 (bufdaemon) 5 0 0 0.0 0.0 DL 0:00.07 (syncer) 83 1 0 0.0 0.4 Ss 0:00.57 syslogd -s 86 1 1 0.0 0.3 Is 0:00.01 /usr/sbin/portmap 102 1 0 0.0 0.5 Is 0:00.13 inetd -wW 104 1 0 0.0 0.5 Is 0:00.04 cron 107 1 0 0.0 0.8 Is 0:00.05 sendmail: accepting connections (sen 111 1 0 0.0 0.8 Is 0:05.88 /usr/sbin/sshd 141 102 0 0.0 0.9 Ss 0:00.37 telnetd 142 141 896 0.0 0.3 Is 0:00.23 -ksh (ksh) 159 142 0 0.0 0.3 S 0:00.26 -su (ksh) 206 159 0 0.0 0.2 R+ 0:00.00 /bin/ps -axo pid aux 140 1 0 0.0 0.4 Is+0:00.05 /usr/libexec/getty Pc console and dmesg: (Yes, the 1st 2 lines are from dmesg, and I cannot find where they are coming from yet). Unrecognized boot flag '0'. Unrecognized boot flag ','. Copyright (c) 1992-2000 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.2-RC1 #0: Thu Nov 16 06:10:10 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ALPHADOG DEC AlphaServer 2100 AlphaServer 2000 4/233, 233MHz 8192 byte page size, 1 processor. CPU: EV45 (21064A) major=6 minor=2 OSF PAL rev: 0x4000c0002012d real memory = 266264576 (260024K bytes) avail memory = 254279680 (248320K bytes) Preloaded elf kernel "kernel" at 0xfc5f8000. md0: Malloc disk pci0: PCI bus on pcib0 sym0: 810 port 0x1-0x100ff mem 0x8108-0x810800ff irq 33 at device 1.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking sym0: interrupting at T2 irq 33 isab0: Intel 82375EB PCI-EISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 pci0: unknown card (vendor=0x1011, dev=0x0004) at 6.0 irq 32 de0: Digital 21143 Fast Ethernet port 0x10100-0x1017f mem 0x81080100-0x8108017f irq 36 at device 7.0 on pci0 de0: interrupting at T2 irq 36 de0: DEC DE500-BA 21143 [10-100Mb/s] pass 3.0 de0: address 00:00:f8:07:3a:b7 pci0: unknown card (vendor=0x10d5, dev=0x0002) at 8.0 irq 37 pci0: unknown card (vendor=0x4f24, dev=0x1721) at 12.0 irq 33 pci0: unknown card (vendor=0x0100, dev=0x0100) at 12.4 irq 65 pci0: unknown card (vendor=0x4f24, dev=0x1721) at 13.0 irq 33 pci0: unknown card (vendor=0x0100, dev=0x0100) at 13.4 irq 65 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: interrupting at T2 irq 6 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd0: interrupting at T2 irq 1 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: interrupting at T2 irq 12 psm0: model Generic PS/2 mouse, device ID 0 mcclock0: MC146818A real time clock at port 0x70-0x71 on isa0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio0: interrupting at T2 irq 4 sio1: reserved for low-level i/o ppc0: Parallel port at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppi0: Parallel I/O on ppbus0 lpt0: Printer on ppbus0 lpt0: Polled port ppc0: interrupting at T2 irq 7
Re: Getting at cardbus CIS data from inside drivers
The problem with a read/seek interface is that you are consuming a resource (a memory window) while you are using it. Yes, but this is the client's resource to use anyway. You'd need an open/close on top of that as well to properly map things in to start and then free them at the end. Plus you might want a ftell sort of interface as well. I'll likely punt on the seek/ftell part. I think it was Jonathan that mentioned that at times when you read one entry you want to skip to another entry that it may reference. I don't have the spec to know, but that is why I thought the flexibility of having a seeking interface might be necessary. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: No console on AlphaServer 2000 4/233 4.2-RC1
Grr... make that 4.2-RC1 FreeBSD 4.2-RC1 #0: Thu Nov 16 06:10:10 EST 2000 -john - John W. De Boskey's Original Message - Hi, Console, console, where's the console? We are attempting to use FreeBSD 4.2-RC2 on an AlphaServer 2000 4/233 and are running into trouble with the console device. When we boot from the CD, it comes up to the boot prompt on the console where we tell it to boot from the cd device. The cd then boots up to the following: /stand/sysinstall running as init on serial console These are the predefined terminal types available to sysinstall when running stand-alone. Please choose the closest match for your particular terminal. 1 .. Standard ANSI terminal. 2 .. VT100 or compatible terminal. 3 .. FreeBSD system console (color) 4 .. FreeBSD system console (monochrome) 5 .. xterm terminal emulator Your choice: (1-5) At this point, no keyboard input is accepted. We then successfully installed onto an AlphaServer 1000 and moved the disks to the 2000. At this point the console is still useless, but we can telnet into the machine and use it... I've included the dmesg output below. Note, on the console after boot, but right before the useless login prompt: Cannot open /dev/ttyv0: not such device or address and from ls: %ls -al /dev/ttyv0 crw--- 1 root wheel 12, 0 Nov 21 10:02 /dev/ttyv0 So, it seems getty can't open the virtual terminal devices. A ps -aux right after boot: PID PPID UID %CPU %MEM STAT TIME COMMAND 0 0 0 0.0 0.0 DLs0:00.00 (swapper) 1 0 0 0.0 0.2 ILs0:00.03 (init) 2 0 0 0.0 0.0 DL 0:00.00 (pagedaemon) 3 0 0 0.0 0.0 DL 0:00.00 (vmdaemon) 4 0 0 0.0 0.0 DL 0:00.00 (bufdaemon) 5 0 0 0.0 0.0 DL 0:00.07 (syncer) 83 1 0 0.0 0.4 Ss 0:00.57 syslogd -s 86 1 1 0.0 0.3 Is 0:00.01 /usr/sbin/portmap 102 1 0 0.0 0.5 Is 0:00.13 inetd -wW 104 1 0 0.0 0.5 Is 0:00.04 cron 107 1 0 0.0 0.8 Is 0:00.05 sendmail: accepting connections (sen 111 1 0 0.0 0.8 Is 0:05.88 /usr/sbin/sshd 141 102 0 0.0 0.9 Ss 0:00.37 telnetd 142 141 896 0.0 0.3 Is 0:00.23 -ksh (ksh) 159 142 0 0.0 0.3 S 0:00.26 -su (ksh) 206 159 0 0.0 0.2 R+ 0:00.00 /bin/ps -axo pid aux 140 1 0 0.0 0.4 Is+0:00.05 /usr/libexec/getty Pc console and dmesg: (Yes, the 1st 2 lines are from dmesg, and I cannot find where they are coming from yet). Unrecognized boot flag '0'. Unrecognized boot flag ','. Copyright (c) 1992-2000 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.2-RC1 #0: Thu Nov 16 06:10:10 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ALPHADOG DEC AlphaServer 2100 AlphaServer 2000 4/233, 233MHz 8192 byte page size, 1 processor. CPU: EV45 (21064A) major=6 minor=2 OSF PAL rev: 0x4000c0002012d real memory = 266264576 (260024K bytes) avail memory = 254279680 (248320K bytes) Preloaded elf kernel "kernel" at 0xfc5f8000. md0: Malloc disk pci0: PCI bus on pcib0 sym0: 810 port 0x1-0x100ff mem 0x8108-0x810800ff irq 33 at device 1.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking sym0: interrupting at T2 irq 33 isab0: Intel 82375EB PCI-EISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 pci0: unknown card (vendor=0x1011, dev=0x0004) at 6.0 irq 32 de0: Digital 21143 Fast Ethernet port 0x10100-0x1017f mem 0x81080100-0x8108017f irq 36 at device 7.0 on pci0 de0: interrupting at T2 irq 36 de0: DEC DE500-BA 21143 [10-100Mb/s] pass 3.0 de0: address 00:00:f8:07:3a:b7 pci0: unknown card (vendor=0x10d5, dev=0x0002) at 8.0 irq 37 pci0: unknown card (vendor=0x4f24, dev=0x1721) at 12.0 irq 33 pci0: unknown card (vendor=0x0100, dev=0x0100) at 12.4 irq 65 pci0: unknown card (vendor=0x4f24, dev=0x1721) at 13.0 irq 33 pci0: unknown card (vendor=0x0100, dev=0x0100) at 13.4 irq 65 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: interrupting at T2 irq 6 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd0: interrupting at T2 irq 1 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: interrupting at T2 irq 12 psm0: model Generic PS/2 mouse, device ID 0 mcclock0: MC146818A real time clock at port 0x70-0x71 on isa0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A sio0: interrupting at
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes: : The problem with a read/seek interface is that you are consuming a : resource (a memory window) while you are using it. : : Yes, but this is the client's resource to use anyway. IIRC, it is shared at the bridge, so the client driver needs to conserve this resource. The comment was more of a thnking out loud for the need to have an open and close (or in this case map and unmap) around its use. : You'd need an : open/close on top of that as well to properly map things in to start : and then free them at the end. Plus you might want a ftell sort of : interface as well. I'll likely punt on the seek/ftell part. : : I think it was Jonathan that mentioned that at times when you read : one entry you want to skip to another entry that it may reference. : I don't have the spec to know, but that is why I thought the flexibility : of having a seeking interface might be necessary. That's one reason that I'd want the callback interface. There are pointers in CIS to other CIS entries that the driver shouldn't care about. However, these are relatively rare, but do appear in multi-function cards (at least for 16-bit cards) and so would likely need to be taken care of. I could have something that would skip ahead, but it wouldn't be a fully general seek/ftell function. That moves more of the processing into the driver than I'd rather see, but I don't see a clean way around it. IIRC, and I haven't looked it up, the CIS entries that would be problematical have two next pointers. One is for the next function, while the other is for the first entry specific to this function. The driver code could look at the CIS entry to tell what to do, and if it was the wrong function, call cis_skip_this_function(dev, cookie, cis); which would skip this function and position the read pointer hidden in the cookie to point to the first entry in the next function's cis (or more accurately, the first entry in the series of entries that are specific to that function). And if you provide this, then people will want to just look at the cis entries for their function only next, which is another interface. Or they will want to search for a certain kind of cis entry. I'm disinclined to make this interface too rich. Oh, and I'd have to make sure that the CIS pointers were sane, which can be hard. One of the problems with the NetBSD code, at least in the past, is that it was too believing that the CIS entries would be compliant with the specs. So certain 16-bit cards would crash the system. It is complications like this that lead me to want to not allow CIS reading at all, but rather provide the commonly parsed information easily to the driver. I don't want drivers groveling through all this stuff to find an ethernet address when the bus is able to parse the CIS and return this on request. Having said that, and based on my experience with some really whacko hardware in the 16-bit world, I think that I can't justify this stand because it makes writing a device driver for whacked out hardware impossible w/o gross hacks (cf older revs of if_xe.c). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: No console on AlphaServer 2000 4/233 4.2-RC2
On Tue, Nov 21, 2000 at 12:59:56PM -0800, John W. De Boskey wrote: Console, console, where's the console? We are attempting to use FreeBSD 4.2-RC2 on an AlphaServer 2000 4/233 and are running into trouble with the console device. When we boot from the CD, it comes up to the boot prompt on the console where we tell it to boot from the cd device. The cd then boots up to the following: /stand/sysinstall running as init on serial console These are the predefined terminal types available to sysinstall when running stand-alone. Please choose the closest match for your particular terminal. 1 .. Standard ANSI terminal. 2 .. VT100 or compatible terminal. 3 .. FreeBSD system console (color) 4 .. FreeBSD system console (monochrome) 5 .. xterm terminal emulator Your choice: (1-5) At this point, no keyboard input is accepted. What video adapter is inside? I'm guessing, but this is not by any chance a TGA-based card is it? FreeBSD/axp does not currently support TGA based adapters. The SRM will use it, but the kernel not once started. I think this is what: /stand/sysinstall running as init on serial console is trying to tell you. -- Wilko Bulte Arnhem, the Netherlands [EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
state of usb?
What is the current state of the usbd? I keep getting messages that complain about a host controller error and a shutdown of the usb interface. And I don't even have any devices on my usb ports... JAN To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
That's what I mean. You call this, and it will remap the CIS (if it has been unmapped), walk it for you and pass you a pointer to each CIS entry one at a time to the function you specify. Warner I'd rather have a seek/read interface than have a callback. Let's be realistic; the right way to do this is going to be to use the ivar interface; cardbus_get_cistuple(dev, index) just like all the other PCI bus accessor functions. PCI will just need to pass the request through to its parent, assuming its parent is a cardbus bridge, or veto it otherwise. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
IIRC, and I haven't looked it up, the CIS entries that would be problematical have two next pointers. One is for the next function, while the other is for the first entry specific to this function. The driver code could look at the CIS entry to tell what to do, and if it was the wrong function, call cis_skip_this_function(dev, cookie, cis); which would skip this function and position the read pointer hidden in the cookie to point to the first entry in the next function's cis (or more accurately, the first entry in the series of entries that are specific to that function). No; the CIS parser should know which function it's being called on behalf of, and simply elide the tuples that don't relate to that function. It is complications like this that lead me to want to not allow CIS reading at all, but rather provide the commonly parsed information easily to the driver. I don't want drivers groveling through all this stuff to find an ethernet address when the bus is able to parse the CIS and return this on request. Having said that, and based on my experience with some really whacko hardware in the 16-bit world, I think that I can't justify this stand because it makes writing a device driver for whacked out hardware impossible w/o gross hacks (cf older revs of if_xe.c). Export the commonly-known stuff through the "right" interface (eg. cardbus_get_cistuple(dev, CARDBUS_CIS_STATION_ADDRESS)) and then provide a backdoor (cardbus_get_cistuple(dev, CARSBUS_CIS_RAW + index)) for the evil side, perhaps. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Mike Smith writes: : That's what I mean. You call this, and it will remap the CIS (if it : has been unmapped), walk it for you and pass you a pointer to each CIS : entry one at a time to the function you specify. : : Warner : : I'd rather have a seek/read interface than have a callback. : : Let's be realistic; the right way to do this is going to be to use the : ivar interface; cardbus_get_cistuple(dev, index) just like all the other : PCI bus accessor functions. PCI will just need to pass the request : through to its parent, assuming its parent is a cardbus bridge, or veto : it otherwise. Why does this have to go even to the bridge? The cardbus bus code already deals with the CIS and it should be the one to arrange things to happen. We can tweak the current cardbus CIS reading stuff to do this and maybe combine it somewhat with the pccard CIS reading stuff. Also, the index doesn't make so much sense because each CIS entry is a variable length, so we'd have to walk the chain. The length is variable, which doesn't work so well with the accessor function which tend to like things to be = sizeof(long). Also, this isn't a PCI thing, so no PCI code should be called. :-) For mapping some parts of the CIS, I think that you need to do that at the cardbus bridge, which means that you can only do that for the cardbus children that are attached. Going up through multiple bridges isn't going to work. This is especially true for the 16-bit CIS entries. Eg, if you have something like the following: pci --- pccbb0 --- cardbus0 --- pcib --- pci -- pccbb0 -- cardbus1 -- dc then when the dc driver wants to map the CIS, the cardbus bus will ask the pccbb to map it, which will go up the usual food chain for mapping, but after it leaves the pccbb it is just a normal map request. The second cardbus bridge (pccbb0) doesn't get into the act of mapping the CIS. Once mapped, cardbus1 will be returning the CIS to dc and also handling the jump discontinuties that can happen in the CIS. This is why I want to have cardbus be its own bus that happens to implement all the pci bus things properly. It is, in C++ terms, a subclass: it is a pci bus plus a few other things. I don't think we should try to shoehorn it all into the PCI bus code. Something tells me that it will result in chaos. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
: Let's be realistic; the right way to do this is going to be to use the : ivar interface; cardbus_get_cistuple(dev, index) just like all the other : PCI bus accessor functions. PCI will just need to pass the request : through to its parent, assuming its parent is a cardbus bridge, or veto : it otherwise. Why does this have to go even to the bridge? Because it's the bridge driver that has to parse the CIS; it needs it to eg. set power and so forth. And because the bus code should be generic. The cardbus bus code already deals with the CIS and it should be the one to arrange things to happen. We can tweak the current cardbus CIS reading stuff to do this and maybe combine it somewhat with the pccard CIS reading stuff. Also, the index doesn't make so much sense because each CIS entry is a variable length, so we'd have to walk the chain. Index is the tuple index, not the byte offset in the CIS; sorry I didn't make that clear. Also, this isn't a PCI thing, so no PCI code should be called. :-) Interrupts aren't a PCI thing either, but we pass attempts by PCI drivers to do stuff with them up through the stack. This really isn't any different. For mapping some parts of the CIS, I think that you need to do that at the cardbus bridge, which means that you can only do that for the cardbus children that are attached. Going up through multiple bridges isn't going to work. This is especially true for the 16-bit CIS entries. Yeah; I don't think I was proposing anything like this. Eg, if you have something like the following: pci --- pccbb0 --- cardbus0 --- pcib --- pci -- pccbb0 -- cardbus1 -- dc then when the dc driver wants to map the CIS, the cardbus bus will ask the pccbb to map it, which will go up the usual food chain for mapping, but after it leaves the pccbb it is just a normal map request. The second cardbus bridge (pccbb0) doesn't get into the act of mapping the CIS. Once mapped, cardbus1 will be returning the CIS to dc and also handling the jump discontinuties that can happen in the CIS. This is why I want to have cardbus be its own bus that happens to implement all the pci bus things properly. It is, in C++ terms, a subclass: it is a pci bus plus a few other things. I don't think we should try to shoehorn it all into the PCI bus code. Something tells me that it will result in chaos. I think that you're overrating the things that need to be "shoehorned" into PCI to make it a comfortable superset of stock PCI + hot-plug PCI + CardBus. So far all we have is passing through a CIS tuple accessor function. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Mike Smith writes: : No; the CIS parser should know which function it's being called on behalf : of, and simply elide the tuples that don't relate to that function. This isn't always the right thing to do. At least in the 16-bit world, there are drivers that want to look at the CIS entries for the other function of the card for various reasons (some of them need to know what kind of modem is present, iirc, to initalize some things in a non-standard way, the example was the NetBSD driver mhz, iirc). I don't wish to preclude that. : Export the commonly-known stuff through the "right" interface : (eg. cardbus_get_cistuple(dev, CARDBUS_CIS_STATION_ADDRESS)) and then : provide a backdoor (cardbus_get_cistuple(dev, CARSBUS_CIS_RAW + index)) : for the evil side, perhaps. Right now pccard exports this as: uchar8_t ether_addr[ETEHR_ADDR_LEN]; pccard_get_ether(dev, ether_addr); where pccard_get_ether is generated by really ugly, but usefully stolen from pci, macros in dev/pccard/pccardvar.h. The OLDCARD code set this from the userland after parsing the CIS. NEWCARD currently doesn't implement this correctly, but will need to do so shortly. I'd like to do exactly the same thing for cardbus: uchar8_t ether_addr[ETEHR_ADDR_LEN]; cardbus_get_ether(dev, ether_addr); to make things easy. I don't think that we can easily do the index thing for CIS entries, for reasons that I've talked about before. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Mike Smith writes: : : Let's be realistic; the right way to do this is going to be to use the : : ivar interface; cardbus_get_cistuple(dev, index) just like all the other : : PCI bus accessor functions. PCI will just need to pass the request : : through to its parent, assuming its parent is a cardbus bridge, or veto : : it otherwise. : : Why does this have to go even to the bridge? : : Because it's the bridge driver that has to parse the CIS; it needs it to : eg. set power and so forth. And because the bus code should be generic. I don't think that the bridge driver should parse the CIS. The bus driver should do the parsing. The bridge driver may be asked by the bus driver to do mapping and such, but it shouldn't do the parsing of the CIS. This is a card services vs socket services issue. I want to be able to implement card services and socket services (maybe in a form different than the pccard spec states). Other card services, from the spec, include resource management (which the bus does), cis traversal, bulk memory services, cis verification, and event managment (note that socket services generate these events and card services respond to them) and some power management issues. All the flash MDTs are handled here as well. Many of these are unique to cardbus and pccard. Many of these are shared with pci. The mapping into FreeBSD's newbus has been a little fuzzy. The experience from the 16-bit days was that one can have different PCIC bridges that the pccard bus sits on top of. There are at least 4 different APIs to talk to the pcic bridge that I know of (pcic (i82365), pcic98 (a custom NEC part found on some pc98 laptops (including mine!)), tcic (an 8-bit pccard interface) and some sbus chip that I know nothing about). We don't want to have the CIS parsing code replicated in each one. While there is only one known cardbus bridge API today, I don't want to architect something that will be hard to have a different one should it become necessary if there's a cardbusII bridge based on pcix that has a legacy way to support cardbus1 (for example). : The cardbus bus code : already deals with the CIS and it should be the one to arrange things : to happen. We can tweak the current cardbus CIS reading stuff to do : this and maybe combine it somewhat with the pccard CIS reading stuff. : Also, the index doesn't make so much sense because each CIS entry is a : variable length, so we'd have to walk the chain. : : Index is the tuple index, not the byte offset in the CIS; sorry I didn't : make that clear. I'm not sure that I follow what you mean by tuple index then. Is that the Nth CIS, or the CIS of type N? If it is the Nth cis, then we do have to walk N-1 CIS tuples to find it. If it is the CIS of type N, then how do we do multiple ones of type N (which is legal and happens for the config entries)? The CIS is an array of bytes. It lives in 1 or more address spaces. Each CIS tuple contains a length (which is used to find the next one). Some CIS tuples are multi-function chaining tuples and contain two lengths, one of the current CIS tuple, and the aggregate length of all tuples for this function. I do not recall if there's a function number in it, but that is implicit from where we are in the CIS. Each CIS tuple is between 2 and 254 bytes long. To find the Nth one, I have to know where the N-1th one ends for all values of N 0. The 0th element is pointed to by the CIS pointer in the pci config space. : Also, this isn't a PCI thing, so no PCI code should be called. :-) : : Interrupts aren't a PCI thing either, but we pass attempts by PCI drivers : to do stuff with them up through the stack. This really isn't any : different. I do think it is different, but maybe we're arguing about semantics here. I'm talking about having the cardbus bus (cardbusN) code do the parsing of the CIS, while asking for assistance from the cardbus bridge code (pccbbN) to apply power to the slot, map in address spaces, etc. The carbus bus code can generically parse the CIS and dole it out to its children by asking the bridge to do certain specific things. The bridge shouldn't be doing the actual parsing. This is a layering argument. The bus is where the resource allocation book keeping takes place, and we'd need it to do that for the CIS stuff that has been mapped so that if the card driver is a bad citizen, it can cleanup properly. I guess I fear putting the cardbus bus function in the cardbus bridge and teaching a regular pci bus to pass them through. I'd rather have the pci bus code reject such attempts and the cardbus bus code process them. : I think that you're overrating the things that need to be "shoehorned" : into PCI to make it a comfortable superset of stock PCI + hot-plug PCI + : CardBus. So far all we have is passing through a CIS tuple accessor : function. 8) It isn't just an accessor to a configuration space, like PCI has. It is
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Mike Smith writes: : No; the CIS parser should know which function it's being called on behalf : of, and simply elide the tuples that don't relate to that function. This isn't always the right thing to do. At least in the 16-bit world, there are drivers that want to look at the CIS entries for the other function of the card for various reasons (some of them need to know what kind of modem is present, iirc, to initalize some things in a non-standard way, the example was the NetBSD driver mhz, iirc). I don't wish to preclude that. The ROM BAR is only implemented for function 0 and the ROM contains information for all functions of the chip. So, functions greater than 0 must have the flexibility to activate at least the ROM BAR on function 0 as well as access that region. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] Mike Smith writes: : No; the CIS parser should know which function it's being called on behalf : of, and simply elide the tuples that don't relate to that function. This isn't always the right thing to do. At least in the 16-bit world, there are drivers that want to look at the CIS entries for the other function of the card for various reasons (some of them need to know what kind of modem is present, iirc, to initalize some things in a non-standard way, the example was the NetBSD driver mhz, iirc). I don't wish to preclude that. The ROM BAR is only implemented for function 0 and the ROM contains information for all functions of the chip. So, functions greater than 0 must have the flexibility to activate at least the ROM BAR on function 0 as well as access that region. Does the driver need the ROM, or the CIS which may be inside the ROM? If the driver needs structured information from inside the ROM, this falls into the same category as the CIS. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
In message [EMAIL PROTECTED] "Justin T. Gibbs" writes: : The ROM BAR is only implemented for function 0 and the ROM : contains information for all functions of the chip. So, functions : greater than 0 must have the flexibility to activate at least the ROM : BAR on function 0 as well as access that region. I think there's a difference between where the CIS actually lives, and the CIS chains for the each function. cardbus cards give each function its own CIS chain. These CIS chains can live in configuration space, in memory space or the expansion ROM (which I assume is the same thing as the ROM BAR on function 0, but maybe I'm mistaken) and the bridge is responsible for properlly mapping the last two. The config space presents the biggest problem because we don't have any way to access it with the bus_space(9) functions, so special code is needed in the cardbus bus driver to know where to read from. I talked with YAMAMOTO shigeru-san at BSDcon about an extension to the bus_space code to allow user defined regions/functions to be used so that one can write generic code to access each of these regions with bus_space_read/write_N. Since this is getting off topic, I'll leave it there, but it looked cool and many of the issues I could think of to bring up were handled well. I also made an error in a previous message. 16-bit and 32bit cis parsing is somewhat different. 16-bit cards effectively have the functions comingled with global entries, while cardbus segregates them. With cardbus the iterated chain would just contain CIS entries for that function. They designed things this way so that the functions could be completely separate, integrated only on an ASIC at the last minute before being placed on a cardbus card :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Getting at cardbus CIS data from inside drivers
function its own CIS chain. These CIS chains can live in configuration space, in memory space or the expansion ROM (which I assume is the same thing as the ROM BAR on function 0, but maybe I'm mistaken) and the bridge is responsible for properlly mapping the last two. The config space presents the biggest problem because we don't have any way to access it with the bus_space(9) functions, so special code is needed in the cardbus bus driver to know where to read from. The code reading the CIS should be using callbacks into the hardware-specific code, which will know how to read/write PCI configuration space. Having said that, there's a good argument to be made for adding PCI configuration space as a new bus_space type. Any thoughts on why this might be a bad idea? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
