Re: vty3 and 4.0 snap 080799
Use alt-F4 for the shell during install. vty0 - alt-F1 [Install] vty1 - alt-F2 [Debug] vty2 - alt-f3 [Inactive] vty3 - alt-F4 [Shell] PrtScr will cycle through all available vty's. HTH. HAND :) Larry Lile [EMAIL PROTECTED] On Wed, 11 Aug 1999 [EMAIL PROTECTED] wrote: At 02:45 PM 08/11/1999 +0200, Dag-Erling Smorgrav wrote: "Michael A. Endsley" [EMAIL PROTECTED] writes: I just downloaded the latest snap (080799) and tried installing it. When getting to the media section and configuring ppp for a ftp install, I try going to vty3 (alt-f3). However, that vty is not available. I have tried this 3 times now. Is this broken? ttyv3 is on Alt-F4. I realized my typing mistake after sending this to the group, but hoped that the "alt-F3" would help. Lets just use alt-f3. To further explain (?): During a fresh install the system uses vty0. When the time comes to finally start downloading (using FTP), a screen is shown telling the person to go use the ALT-F3 keys (vty2) to use term. For me, that key combination is not "active". In fact, just vty1 is available (to view what FreeBSD is doing). I will just download the floppies from a later date (19990808-11). Thanks Mike ps- sorry for some of the generalities...I am just going by memory w/o being able to see the screens. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: vty3 and 4.0 snap 080799
The shell is not started until after the install starts, ie when the ftp connects (the dists start getting untarred.) Larry Lile On Wed, 11 Aug 1999 [EMAIL PROTECTED] wrote: I should have also stated that I tried all the other "F" keys also. The only vty that is available/active is vty1 for debugging. Every other F-key gets the "beep". HTH in solving my problem fwiw dept.- I have been using FreeBSD since 2.21-R To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Patch to fix [Re: Bad, reliable crash: Julian's oltr stuff ARP]
The problem Mr. Pallfreeman was seeing are related to how I was
building the arp-reply based on the sources arp_hrd type. I never
expected to see a token-ring arp arrive over an ethernet interface.
Therefore the arp code was trying to check for and collect the
source route that the arp took on its way. I have modified the
arp code to go looking for the source-route information only if
the arp comes from a token-ring station and is received on a
token-ring interface. The arp-reply packet generated is based
on the type of interface the arp was received on. I think
the bridge should have changed the arp_hrd type when it forwarded
the packet, while it was changing everything else, but I think
that falls into a religous debate. Thanks to Mr. Pallfreeman
for helping me debug this and testing my patch.
What this means is: you should be able to arp in both directions
over a token-ring-ethernet (translational|non-translational) bridge.
The inherent brokenness of translational bridging is left as an
exercise for the reader :)
Here's the patch, if someone would be kind enough to commit it. It
seems to have resolved Mr. Pallfreeman's issue and doesn't seem to
break anything else.
Larry Lile
l...@stdio.com
*** if_ether.c.orig Wed Apr 14 09:54:35 1999
--- if_ether.c Wed Apr 14 12:50:02 1999
***
*** 560,567
(void)memcpy(LLADDR(sdl), ea-arp_sha, sizeof(ea-arp_sha));
sdl-sdl_alen = sizeof(ea-arp_sha);
sdl-sdl_rcf = NULL;
! /* Save source routing information for Token-ring interfaces,
if available */
! if (ea-arp_hrd == htons(ARPHRD_IEEE802)) {
th = (struct iso88025_header *)m-m_pkthdr.header;
if ((th-iso88025_shost[0] 0x80) (((ntohs(th-rcf)
0x1f00) 8) 2)) {
sdl-sdl_rcf = ntohs(th-rcf) 0x0080 ?
--- 560,569
(void)memcpy(LLADDR(sdl), ea-arp_sha, sizeof(ea-arp_sha));
sdl-sdl_alen = sizeof(ea-arp_sha);
sdl-sdl_rcf = NULL;
! /* If we receive an arp from a token-ring station over a
token-ring nic
!* then try to save the source routing info.
!*/
! if ((ac-ac_if.if_type == IFT_ISO88025) (ea-arp_hrd ==
htons(ARPHRD_IEEE802))) {
th = (struct iso88025_header *)m-m_pkthdr.header;
if ((th-iso88025_shost[0] 0x80) (((ntohs(th-rcf)
0x1f00) 8) 2)) {
sdl-sdl_rcf = ntohs(th-rcf) 0x0080 ?
***
*** 578,583
--- 580,587
}
th-rcf = sdl-sdl_rcf;
+ } else {
+ sdl-sdl_rcf = NULL;
}
if (rt-rt_expire)
rt-rt_expire = time_second + arpt_keep;
***
*** 647,654
(void)memcpy(ea-arp_spa, itaddr, sizeof(ea-arp_spa));
ea-arp_op = htons(ARPOP_REPLY);
ea-arp_pro = htons(ETHERTYPE_IP); /* let's be sure! */
! switch (ntohs(ea-arp_hrd)) {
! case ARPHRD_IEEE802:
/* Re-arrange the source/dest address */
memcpy(th-iso88025_dhost, th-iso88025_shost,
sizeof(th-iso88025_dhost));
memcpy(th-iso88025_shost, ac-ac_enaddr,
sizeof(th-iso88025_shost));
--- 651,658
(void)memcpy(ea-arp_spa, itaddr, sizeof(ea-arp_spa));
ea-arp_op = htons(ARPOP_REPLY);
ea-arp_pro = htons(ETHERTYPE_IP); /* let's be sure! */
! switch (ac-ac_if.if_type) {
! case IFT_ISO88025:
/* Re-arrange the source/dest address */
memcpy(th-iso88025_dhost, th-iso88025_shost,
sizeof(th-iso88025_dhost));
memcpy(th-iso88025_shost, ac-ac_enaddr,
sizeof(th-iso88025_shost));
***
*** 663,669
sa.sa_data[(sizeof(th-iso88025_dhost) * 2)] = 0x10;
sa.sa_data[(sizeof(th-iso88025_dhost) * 2) + 1] = 0x40;
break;
! case ARPHRD_ETHER:
eh = (struct ether_header *)sa.sa_data;
(void)memcpy(eh-ether_dhost, ea-arp_tha,
sizeof(eh-ether_dhost));
eh-ether_type = htons(ETHERTYPE_ARP);
--- 667,673
sa.sa_data[(sizeof(th-iso88025_dhost) * 2)] = 0x10;
sa.sa_data[(sizeof(th-iso88025_dhost) * 2) + 1] = 0x40;
break;
! case IFT_ETHER:
eh = (struct ether_header *)sa.sa_data;
(void)memcpy(eh-ether_dhost, ea-arp_tha,
sizeof(eh-ether_dhost));
eh-ether_type = htons(ETHERTYPE_ARP);
Re: Patch to fix [Re: Bad, reliable crash: Julian's oltr stuff ARP]
Okay, that one is just a little too strong. It won't allow
a FreeBSD token-ring station to arp-reply to an ethernet station
on the other side of a broken translational bridge. This one
will.
Larry Lile
l...@stdio.com
On Wed, 14 Apr 1999, Larry Lile wrote:
The problem Mr. Pallfreeman was seeing are related to how I was
building the arp-reply based on the sources arp_hrd type. I never
expected to see a token-ring arp arrive over an ethernet interface.
Therefore the arp code was trying to check for and collect the
source route that the arp took on its way. I have modified the
arp code to go looking for the source-route information only if
the arp comes from a token-ring station and is received on a
token-ring interface. The arp-reply packet generated is based
on the type of interface the arp was received on. I think
the bridge should have changed the arp_hrd type when it forwarded
the packet, while it was changing everything else, but I think
that falls into a religous debate. Thanks to Mr. Pallfreeman
for helping me debug this and testing my patch.
What this means is: you should be able to arp in both directions
over a token-ring-ethernet (translational|non-translational) bridge.
The inherent brokenness of translational bridging is left as an
exercise for the reader :)
Here's the patch, if someone would be kind enough to commit it. It
seems to have resolved Mr. Pallfreeman's issue and doesn't seem to
break anything else.
Larry Lile
l...@stdio.com
*** if_ether.c.orig Mon Mar 8 13:22:41 1999
--- if_ether.c Wed Apr 14 14:43:41 1999
***
*** 559,566
(void)memcpy(LLADDR(sdl), ea-arp_sha, sizeof(ea-arp_sha));
sdl-sdl_alen = sizeof(ea-arp_sha);
sdl-sdl_rcf = NULL;
! /* Save source routing information for Token-ring interfaces,
if available */
! if (ea-arp_hrd == htons(ARPHRD_IEEE802)) {
th = (struct iso88025_header *)m-m_pkthdr.header;
if ((th-iso88025_shost[0] 0x80) (((ntohs(th-rcf)
0x1f00) 8) 2)) {
sdl-sdl_rcf = ntohs(th-rcf) 0x0080 ?
--- 559,568
(void)memcpy(LLADDR(sdl), ea-arp_sha, sizeof(ea-arp_sha));
sdl-sdl_alen = sizeof(ea-arp_sha);
sdl-sdl_rcf = NULL;
! /* If we receive an arp from a token-ring station over a
token-ring nic
!* then try to save the source routing info.
!*/
! if (ac-ac_if.if_type == IFT_ISO88025) {
th = (struct iso88025_header *)m-m_pkthdr.header;
if ((th-iso88025_shost[0] 0x80) (((ntohs(th-rcf)
0x1f00) 8) 2)) {
sdl-sdl_rcf = ntohs(th-rcf) 0x0080 ?
***
*** 577,582
--- 579,586
}
th-rcf = sdl-sdl_rcf;
+ } else {
+ sdl-sdl_rcf = NULL;
}
if (rt-rt_expire)
rt-rt_expire = time_second + arpt_keep;
***
*** 646,653
(void)memcpy(ea-arp_spa, itaddr, sizeof(ea-arp_spa));
ea-arp_op = htons(ARPOP_REPLY);
ea-arp_pro = htons(ETHERTYPE_IP); /* let's be sure! */
! switch (ntohs(ea-arp_hrd)) {
! case ARPHRD_IEEE802:
/* Re-arrange the source/dest address */
memcpy(th-iso88025_dhost, th-iso88025_shost,
sizeof(th-iso88025_dhost));
memcpy(th-iso88025_shost, ac-ac_enaddr,
sizeof(th-iso88025_shost));
--- 650,657
(void)memcpy(ea-arp_spa, itaddr, sizeof(ea-arp_spa));
ea-arp_op = htons(ARPOP_REPLY);
ea-arp_pro = htons(ETHERTYPE_IP); /* let's be sure! */
! switch (ac-ac_if.if_type) {
! case IFT_ISO88025:
/* Re-arrange the source/dest address */
memcpy(th-iso88025_dhost, th-iso88025_shost,
sizeof(th-iso88025_dhost));
memcpy(th-iso88025_shost, ac-ac_enaddr,
sizeof(th-iso88025_shost));
***
*** 662,668
sa.sa_data[(sizeof(th-iso88025_dhost) * 2)] = 0x10;
sa.sa_data[(sizeof(th-iso88025_dhost) * 2) + 1] = 0x40;
break;
! case ARPHRD_ETHER:
eh = (struct ether_header *)sa.sa_data;
(void)memcpy(eh-ether_dhost, ea-arp_tha,
sizeof(eh-ether_dhost));
eh-ether_type = htons(ETHERTYPE_ARP);
--- 666,672
sa.sa_data[(sizeof(th-iso88025_dhost) * 2)] = 0x10;
sa.sa_data[(sizeof(th-iso88025_dhost) * 2) + 1] = 0x40;
break;
! case IFT_ETHER:
eh = (struct ether_header *)sa.sa_data;
(void)memcpy(eh-ether_dhost, ea-arp_tha,
sizeof(eh-ether_dhost));
eh-ether_type = htons(ETHERTYPE_ARP);
Re: Bad, reliable crash: Julian's oltr stuff ARP
Just so Julian doesn't get blamed here, I was the one who wrote the Olicom oltr driver and made the arp changes. Julian was just nice enough to commit them. The only thing I can figure, as I can't tell exactly what caused it to punt, is that you received a token-ring arp packet that is somewhat damaged. Is there a token-ring-ethernet bridge on your network? What was it doing in in_arpinput when it panic'd? Larry Lile l...@stdio.com On Mon, 12 Apr 1999, Ian Pallfreeman wrote: My -current trashbox is having some pretty severe problems which seem to stem from the token ring additions on March 10th. The box in question wouldn't stay up for more than a few minutes. ``savecore'' isn't working for me right now, but I've managed to delete a single line of code which lets the box stay up long enough for me to do a make world and get to grips with all this EGCS, uh, fun. This isn't a true solution, obviously. The ethernet segment to which the box is connected has lots of non-IP traffic (DECNET, Novell, etc), but I didn't expect to find token ring stuff on it. :-) Ian. *** if_ether.c.orig Mon Apr 12 16:11:12 1999 --- if_ether.c Mon Apr 12 16:13:22 1999 *** *** 435,442 panic(arpintr); if (m-m_len = sizeof(struct arphdr) (ar = mtod(m, struct arphdr *)) ! (ntohs(ar-ar_hrd) == ARPHRD_ETHER || ! ntohs(ar-ar_hrd) == ARPHRD_IEEE802) m-m_len = sizeof(struct arphdr) + 2 * ar-ar_hln + 2 * ar-ar_pln) --- 435,441 panic(arpintr); if (m-m_len = sizeof(struct arphdr) (ar = mtod(m, struct arphdr *)) ! ntohs(ar-ar_hrd) == ARPHRD_ETHER m-m_len = sizeof(struct arphdr) + 2 * ar-ar_hln + 2 * ar-ar_pln) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc017e590 stack pointer = 0x10:0xc02248d8 frame pointer = 0x10:0xc0224928 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres type 0x1b = DPL 0, press 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = kernel: type 12 trap, code=0 Stopped at in_arpinput+0x264: cmpb$0,0x8(%ecx) db tr in_arpinput(c0744100,0,0,c01ee601,c01ee5a3) at in_arpinput+0x264 arpintr(c01ee5a3,8000,10,10,0) at arpintr+0xb4 swi_net_next() at swi_net_next db show registers cs 0x8 ds 0x7e8b0010 es0x10 ss0x10 eax 0x600 ecx 0 edx 0 ebx 0xc0a02490 esp 0xc02255ec __set_pcidevice_set_sym_ide_pci_device+0x2fc0 ebp 0xc022563c __set_pcidevice_set_sym_ide_pci_device+0x3010 esi 0xc073c820 edi 0xc0a2d600 eip 0xc017e3d4 in_arpinput+0x264 efl0x10246 in_arpinput+0x264: cmpb$0,0x8(%ecx) db panic Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #1: Mon Apr 12 16:13:32 BST 1999 i...@trauma:/usr/src/sys/compile/TRAUMA Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 400910920 Hz CPU: Pentium II/Xeon/Celeron (400.91-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping=2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134217728 (131072K bytes) avail memory = 127995904 (124996K bytes) Preloaded elf kernel kernel at 0xc0291000. Pentium Pro MTRR support enabled, default memory type is uncacheable ccd0: Concatenated disk driver Probing for devices on PCI bus 0: chip0: Intel 82443BX host to PCI bridge rev 0x02 on pci0.0.0 chip1: Intel 82443BX host to AGP bridge rev 0x02 on pci0.1.0 chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.7.0 ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.7.1 chip3: Intel 82371AB Power management controller rev 0x02 on pci0.7.3 ahc0: Adaptec 2940 Ultra SCSI adapter rev 0x00 int a irq 10 on pci0.15.0 ahc0: aic7880 Single Channel A, SCSI Id=7, 16/255 SCBs fxp0: Intel EtherExpress Pro 10/100B Ethernet rev 0x05 int a irq 12 on pci0.17.0 fxp0: Ethernet address 00:90:27:10:2b:ea Probing for devices on PCI bus 1: vga0: S3 model 8904 graphics accelerator rev 0x01 int a irq 255 on pci1.0.0 Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A, console sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7
Re: CardBus Support (was: support for 3Com 3C575 network controller?)
terry_mur...@3com.com is the holder of technical docs great and small
at 3com. There is some doc request that you can fax in, but it is
very old and out of date, she is listed as the contact. She has
gotten me a couple of docs that I couldn't find.
Larry Lile
l...@stdio.com
On Sat, 20 Feb 1999, Lyndon Nerenberg wrote:
I've been trying to get some progamming doc out of TI for
the PCI1200 PCI/Cardbus bridge (used in the Dell Inspiron
7000), however they cannot seem to understand that I'm not
asking for a pre-written device driver :-(
Does anyone out there have doc for the PCI1200 (and
preferably the entire PCI12xx family) they could send me?
Or have a knowledgable contact inside TI that could send
same to me?
--lyndon
# CardBus cards aren't supported. Period.
Eek, I didn't realize this was a CardBus card. :{ I quess
this begs the question though, is anyone working on CardBus
support for FreeBSD since this is the 32-bit version of
PCMCIA? Yes I understand they are *completely* different.
Just curious.
No-one is actively working on it right now. I do own one of the cards and
it should be possible to use the existing xl driver without too many
changes after the initial cardbus hurdle is dealt with. Paid work is
monopolising my time right now, so I don't expect to play with it anytime
soon.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
