PCMCIA, IBMTR_CS, ARP-HW-TYPE
I forward this problem to the lfs-dev-list now. If anybody can give me a hint where to start searching the problem in the kernel code, I'll try to fix it. Claus -- Original Message Subject: Re: PCMCIA, IBMTR_CS, ARP-HW-TYPE Date: Sat, 3 Oct 2009 10:29:34 -0800 From: ALIP BUDIANTO Reply-To: BLFS Support List To: BLFS Support List References: <4ac796ee.5070...@rgc1.inka.de> If its the kernel mabye yes. If its on only BLFS stay here unlesss the LFS build affects BLFS. On Sat, Oct 3, 2009 at 10:24 AM, Claus Regelmann wrote: > Richard Melville wrote: >> >> >> Claus Regelmann said:- >> >> >> >> I recently finished installing LFS 6.5 on my old Laptop (IBM-T21). >> I added SYSFSUTILS-2.1.0 and PCMCIAUTILS-0.15, put the TR card in, >> called pcmcia-socket-startup, found the tr0 interface, configured >> tr0, and tried to ping another machine in my network. >> -- no response -- >> I continued investigating the situation with wireshark, and found >> that my T21 sends ARP requests and responces with an unknown HW type >> of 0x320.The correct HW type should be 0x06. >> >> Where does the wrong HW type come from?? >> 'cat /sys/bus/pcmcia/devices/0.0/net/tr0/type' displays 800, which >> is equal to 0x320 >> >> Do you have all the correct drivers configured in the kernel? >> >> Richard >> > > Yes, all modules are loaded and the link layer is running. The problem > comes form the arp traffic where my T21 uses a wrong ARPHRD value. > But I found a qnd work arround that works for me: > -- patch for ibmtr_cs.c --- >/* Set up the Token-Ring Controller Configuration Register and > turn on the card. Check the "Local Area Network Credit Card > Adapters Technical Reference" SC30-3585 for this info. */ > ibmtr_hw_setup(dev, mmiobase); > -> dev->type=0x06; > -> printk (KERN_INFO " ibmtr_cs after HW setup: dev->type=%d\n",dev->type); > > link->dev_node = &info->node; > > But this patch is not a real fix! > > if you lock into include/linux/if_arp.h you will find > #define ARPHRD_IEEE802 6 > ... and ... > #define ARPHRD_IEEE802_TR 800 > > I've several desktops in my net, the oldest one has even an ISA adapter > (module ibmtr), > the others have IBM-PCI adapter (module olympic), and all these machines use > ARPHRD_IEEE802. > > So the remaining question is: why does 'ibmtr_cs' use ARPHRD_IEEE802_TR. > > Shall I submit this problem to the LFS-DEV mailing list? > > Claus > > P.S.: I also tested a very old PS/2 micro channel machine. It also uses > ARPHRD_IEEE802. > -- > http://linuxfromscratch.org/mailman/listinfo/blfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Appendix: Sorry Richard, i haven't answered you question correctly. The anwer is no. The drivers are all modules loaded by udev. Here is the module list -- r...@newlfs:~# lsmod Module Size Used by ibmtr_cs 15860 1 tr 5292 1 ibmtr_cs,[permanent] nfsd 194916 8 lockd 55340 1 nfsd auth_rpcgss29260 1 nfsd sunrpc147836 7 nfsd,lockd,auth_rpcgss exportfs3564 1 nfsd snd_cs46xx 69276 0 snd_rawmidi17120 1 snd_cs46xx snd_seq_device 5376 1 snd_rawmidi snd_ac97_codec 85724 1 snd_cs46xx pcmcia 27204 1 ibmtr_cs ac97_bus1268 1 snd_ac97_codec snd_pcm56120 2 snd_cs46xx,snd_ac97_codec snd_timer 16320 1 snd_pcm nsc_ircc 13820 0 snd41776 6 snd_cs46xx,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcm,snd_timer parport_pc 27608 0 ide_cd_mod 23984 0 thinkpad_acpi 55484 0 uhci_hcd 18780 0 soundcore 5160 1 snd usbcore 114268 2 uhci_hcd led_class 3364 1 thinkpad_acpi cdrom 28380 1 ide_cd_mod floppy 44520 0 snd_page_alloc 7112 2 snd_cs46xx,snd_pcm parport18488 1 parport_pc irda 92836 1 nsc_ircc yenta_socket 20120 4 rsrc_nonstatic 7564 1 yenta_socket crc_ccitt 1548 1 irda pcmcia_core27332 3 pcmcia,yenta_socket,rsrc_nonstatic r...@newlfs:~# - Claus -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: PCMCIA, IBMTR_CS, ARP-HW-TYPE
Hallo again,
installing OpenSuse 11.2 on desktop maschine with a TR-PCI card (driver
olympic),
I reexperienced the problem described below. I dived further into the problem
-- almost by trial and error -- and found that the error is in
'.../net/ipv4/arp.c' in the function 'arp_create'.
(kernel 2.6.30.4)
/*
* Exceptions everywhere. AX.25 uses the AX.25 PID value not the
* DIX code for the protocol. Make these device structure fields.
*/
printk(KERN_WARNING "arp_create hwtype=%d
%d\n",dev->type,ARPHRD_IEEE802_TR); <type) {
default:
arp->ar_hrd = htons(dev->type);
arp->ar_pro = htons(ETH_P_IP);
break;
#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
case ARPHRD_AX25:
arp->ar_hrd = htons(ARPHRD_AX25);
arp->ar_pro = htons(AX25_P_IP);
break;
#if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE)
case ARPHRD_NETROM:
arp->ar_hrd = htons(ARPHRD_NETROM);
arp->ar_pro = htons(AX25_P_IP);
break;
#endif
#endif
#ifdef CONFIG_FDDI
case ARPHRD_FDDI:
arp->ar_hrd = htons(ARPHRD_ETHER);
arp->ar_pro = htons(ETH_P_IP);
break;
#endif
// #ifdef CONFIG_TR<===
case ARPHRD_IEEE802_TR:
printk(KERN_WARNING "arp_create: IEEE802_TR\n");
arp->ar_hrd = htons(ARPHRD_IEEE802);
arp->ar_pro = htons(ETH_P_IP);
break;
// #endif <==
}
arp->ar_hln = dev->addr_len;
arp->ar_pln = 4;
After commenting the cond. compilation of CONFIG_TR all works.
So the question is why CONFIG_TR is undefined allthought .config says:
...
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_1 is not set
CONFIG_TR=m
# CONFIG_IBMOL is not set
# CONFIG_IBMLS is not set
...
Claus
--
Claus Regelmann wrote:
> I forward this problem to the lfs-dev-list now.
> If anybody can give me a hint where to start searching the problem
> in the kernel code, I'll try to fix it.
>
> Claus
> --
> Original Message
> Subject: Re: PCMCIA, IBMTR_CS, ARP-HW-TYPE
> Date: Sat, 3 Oct 2009 10:29:34 -0800
> From: ALIP BUDIANTO
> Reply-To: BLFS Support List
> To: BLFS Support List
> References:
> <4ac796ee.5070...@rgc1.inka.de>
>
> If its the kernel mabye yes.
> If its on only BLFS stay here unlesss the LFS build affects BLFS.
>
> On Sat, Oct 3, 2009 at 10:24 AM, Claus Regelmann wrote:
>> Richard Melville wrote:
>>>
>>> Claus Regelmann said:-
>>>
>>>
>>>
>>> I recently finished installing LFS 6.5 on my old Laptop (IBM-T21).
>>> I added SYSFSUTILS-2.1.0 and PCMCIAUTILS-0.15, put the TR card in,
>>> called pcmcia-socket-startup, found the tr0 interface, configured
>>> tr0, and tried to ping another machine in my network.
>>> -- no response --
>>> I continued investigating the situation with wireshark, and found
>>> that my T21 sends ARP requests and responces with an unknown HW type
>>> of 0x320.The correct HW type should be 0x06.
>>>
>>> Where does the wrong HW type come from??
>>> 'cat /sys/bus/pcmcia/devices/0.0/net/tr0/type' displays 800, which
>>> is equal to 0x320
>>>
>>> Do you have all the correct drivers configured in the kernel?
>>>
>>> Richard
>>>
>> Yes, all modules are loaded and the link layer is running. The problem
>> comes form the arp traffic where my T21 uses a wrong ARPHRD value.
>> But I found a qnd work arround that works for me:
>> -- patch for ibmtr_cs.c ---
>>/* Set up the Token-Ring Controller Configuration Register and
>> turn on the card. Check the "Local Area Network Credit Card
>> Adapters Technical Reference" SC30-3585 for this info. */
>> ibmtr_hw_setup(dev, mmiobase);
>> -> dev->type=0x06;
>> -> printk (KERN_INFO " ibmtr_cs after HW setup: dev->type=%d\n",dev->type);
>>
>> link->dev_node = &info->node;
>>
>> But this patch is not a real fix!
>>
>> if you lock into include/linux/if_arp.h you
patch for ../net/ipv4/arp.c (former PCMCIA, IBMTR_CS, ARP-HW-TYPE)
I think the attached patch should be made generally available.
For the time it is not included in the kernel, it fixes a problem
with arp-packages on networks other than ethernet (at least for Token Ring).
Claus
- History --
Are the conditional compilations necessary anymore?
If I compare the code with that of kernel 2.6.22.14, I find that
in function arp_process the #ifdefs have already been removed.
So I think we can remove them here as well.
test for me ... works (at least with TR)
David Miller wrote:
> From: Claus Regelmann
> Date: Mon, 10 May 2010 00:39:45 +0200
>
>> So the question is why CONFIG_TR is undefined allthought .config says:
>> ...
>> # CONFIG_NETDEV_1000 is not set
>> # CONFIG_NETDEV_1 is not set
>> CONFIG_TR=m
>
> Because when a configuration setting is set to "m" that makes
> CONFIG_FOO_MODULE get defined instead of plain CONFIG_FOO.
>
> So these places that test CONFIG_TR need to be changed to instead
> test "defined(CONFIG_TR) || defined(CONFIG_TR_MODULE)"
>
-
installing OpenSuse 11.2 on desktop maschine with a TR-PCI card (driver
olympic),
I reexperienced the problem described below. I dived further into the problem
-- almost by trial and error -- and found that the error is in
'.../net/ipv4/arp.c' in the function 'arp_create'.
(kernel 2.6.30.4)
/*
* Exceptions everywhere. AX.25 uses the AX.25 PID value not the
* DIX code for the protocol. Make these device structure fields.
*/
printk(KERN_WARNING "arp_create hwtype=%d %d\n",dev->type,ARPHRD_IEEE802_TR);
<type) {
default:
arp->ar_hrd = htons(dev->type);
arp->ar_pro = htons(ETH_P_IP);
break;
#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
case ARPHRD_AX25:
arp->ar_hrd = htons(ARPHRD_AX25);
arp->ar_pro = htons(AX25_P_IP);
break;
#if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE)
case ARPHRD_NETROM:
arp->ar_hrd = htons(ARPHRD_NETROM);
arp->ar_pro = htons(AX25_P_IP);
break;
#endif
#endif
#ifdef CONFIG_FDDI
case ARPHRD_FDDI:
arp->ar_hrd = htons(ARPHRD_ETHER);
arp->ar_pro = htons(ETH_P_IP);
break;
#endif
// #ifdef CONFIG_TR<===
case ARPHRD_IEEE802_TR:
printk(KERN_WARNING "arp_create: IEEE802_TR\n");
arp->ar_hrd = htons(ARPHRD_IEEE802);
arp->ar_pro = htons(ETH_P_IP);
break;
// #endif <==
}
arp->ar_hln = dev->addr_len;
arp->ar_pln = 4;
After commenting the cond. compilation of CONFIG_TR all works.
So the question is why CONFIG_TR is undefined allthought .config says:
...
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_1 is not set
CONFIG_TR=m
# CONFIG_IBMOL is not set
# CONFIG_IBMLS is not set
...
Claus
diff -Naur linux-2.6.32.8/net/ipv4/arp.c linux-2.6.32.8-cr/net/ipv4/arp.c
--- linux-2.6.32.8/net/ipv4/arp.c 2010-02-09 13:57:19.0 +0100
+++ linux-2.6.32.8-cr/net/ipv4/arp.c2010-05-10 20:50:33.0 +0200
@@ -604,33 +604,22 @@
arp->ar_hrd = htons(dev->type);
arp->ar_pro = htons(ETH_P_IP);
break;
-
-#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
case ARPHRD_AX25:
arp->ar_hrd = htons(ARPHRD_AX25);
arp->ar_pro = htons(AX25_P_IP);
break;
-
-#if defined(CONFIG_NETROM) || defined(CONFIG_NETROM_MODULE)
case ARPHRD_NETROM:
arp->ar_hrd = htons(ARPHRD_NETROM);
arp->ar_pro = htons(AX25_P_IP);
break;
-#endif
-#endif
-
-#ifdef CONFIG_FDDI
case ARPHRD_FDDI:
arp->ar_hrd = htons(ARPHRD_ETHER);
arp->ar_pro = htons(ETH_P_IP);
break;
-#endif
-#ifdef CONFIG_TR
case ARPHRD_IEEE802_TR:
arp->ar_hrd = htons(ARPHRD_IEEE802);
arp->ar_pro = htons(ETH_P_IP);
break;
-#endif
}
arp->ar_hln = dev->addr_len;
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: patch for ../net/ipv4/arp.c (former PCMCIA, IBMTR_CS, ARP-HW-TYPE)
Bruce Dubbs wrote: > The Linux kernel is updated relatively often, many times due to > discoveries of security vulnerabilities. The latest available 2.6.33.x > kernel version should be used, unless the errata page says otherwise. > > We are up to 2.6.32.12 at kernel.org. > > There is no way we can keep up with the kernel changes for a stable > book. We do try to update svn a bit more frequently. > >-- Bruce You are right, LFS cannot keep up with the kernel changes. I already informed the maintainer of the code too (David Miller). But I think at least a NOTE in the stable LFS's errata would be suitable, to prevent others (probably few) from running into the same troubles. It took me a very long time to catch this error (with fun). btw. looking quickly at the code of 2.6.32.12 and 2.6.33.3, these kernels will probably expose the same problem. -- Claus -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: patch for ../net/ipv4/arp.c (former PCMCIA, IBMTR_CS, ARP-HW-TYPE)
Ken Moffat wrote: > On 10 May 2010 20:21, Claus Regelmann wrote: >> I think the attached patch should be made generally available. >> For the time it is not included in the kernel, it fixes a problem >> with arp-packages on networks other than ethernet (at least for Token Ring). >> > > I'm astonished that anyone still uses token ring. I salute your efforts > to keep an obsolete technology going, and I'm known for having used > weird things (for linux,amigaone and ppc64, otherwise jupiter ace, CP/M > on a z80, MVS, and for a couple of months token ring if someone hadn't > unplugged one of the machines), but I think this is a bit *too* far off the > beaten track for LFS. > > Fortunately, google should be able to find it if anyone needs it. > > ĸen Yes! I need it, just for fun, others have their vintage cars. You can learn many,many things from these "obsolete" technologies. Claus -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS 7.3: Check-0.9.9 compile error fix
Hello, the following SED fixed a compile error when I used KNOPPIX 6.7.1 as initial system to build the toolchain: >> sed -i '4s/;$//' lib/putenv.c' << This is simply a typ-o in the source. This error did not occur, when I used SuSE 12.2. as initial system !!! ??? Claus -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS 7.3: Check-0.9.9 compile error fix
On 03/09/2013 12:01 AM, Bruce Dubbs wrote:
> Claus Regelmann wrote:
>> Hello,
>>
>> the following SED fixed a compile error when I used KNOPPIX 6.7.1 as
>> initial system to build the toolchain:
>>>> sed -i '4s/;$//' lib/putenv.c' <<
>> This is simply a typo in the source.
>>
>> This error did not occur, when I used SuSE 12.2. as initial system !!! ???
>
> What is there is equivalent to declaring the function in a header file.
> A grep through the source shows that the function is not used. What's
> the version of gcc in KNOPPIX 6.7.1?
>
> -- Bruce
>
Yes -- it is a prototype declaration, but it shouldn't be one.
The next character is '{'. This is what the compiler correctly complaines.
There may be differences depending on the initial host environment. Under
SuSE and many other systems, this function is not even be compiled.
Look at the 1st line of putenv.c.
The function has something to deal with "compatability".
-- Claus
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] LFS 7.3: Check-0.9.9 compile error fix
On 03/09/2013 02:01 AM, Bruce Dubbs wrote:
> Claus Regelmann wrote:
>> On 03/09/2013 12:01 AM, Bruce Dubbs wrote:
>>> Claus Regelmann wrote:
>>>> Hello,
>>>>
>>>> the following SED fixed a compile error when I used KNOPPIX 6.7.1 as
>>>> initial system to build the toolchain:
>>>> >> sed -i '4s/;$//' lib/putenv.c' <<
>>>> This is simply a typo in the source.
>>>>
>>>> This error did not occur, when I used SuSE 12.2. as initial system !!! ???
>>>
>>> What is there is equivalent to declaring the function in a header file.
>>> A grep through the source shows that the function is not used. What's
>>> the version of gcc in KNOPPIX 6.7.1?
>
>> Yes -- it is a prototype declaration, but it shouldn't be one.
>> The next character is '{'. This is what the compiler correctly complaines.
>
> Yes. I thought about this after I sent the last post.
>
>> There may be differences depending on the initial host environment. Under
>> SuSE and many other systems, this function is not even be compiled.
>> Look at the 1st line of putenv.c.
>> The function has something to deal with "compatability".
>
> I checked my logs and indeed, it is not compiled when using an LFS host.
>
> I'm not sure what is wrong with KNOPPIX that it does not have putenv and
> check wants to build it. configure runs:
>
> ac_fn_c_check_func "$LINENO" "putenv" "ac_cv_func_putenv"
>
> in order to determine if it is present and it should be in libc-2.17.so.
>
> Does KNOPPIX 6.7.1 meet all the requirements of the Host System
> Requirements? Look especially for glibc. For me, I did:
>
> $ nm /lib/libc-2.17.so|grep putenv
> 00037500 T putenv
>
> -- Bruce
>
Hi Bruce,
this is the 1st time I'm building a libc-2.17.so (in the tools/lib).
But relax! IT WORKS with KNOPPIX after correcting the check-typo (the 1st
error-source),
and adding BISON to the toolchain before BASH.
LFS7.3-Chapter 6 successfully finished !!
-- Claus
P.S.: what about a new LFS-Live-CD ?
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Bison/Yacc Host requirement
This decision eliminates the famous KNOPPIX from being used as a startup-system. At least on my CD (version 5.0.1), bison isn't included. However I solved the problem by including bison into the tool chain before building bash. It works with SVN-20061209. build script ... . MakeTools.done ... if [ -z "$BISON_DONE" ];then echo '===' echo 'Building BISON' echo '===' tar -jxvf $PACKDIR/bison-1.875a.tar.bz2 cd bison-1.875a ./configure --prefix=/tools || exit 8 make || exit 8 make check || exit 8 make install || exit 8 cd .. rm -rf bison-1.875a echo 'BISON_DONE="bison-1.875a"' >>MakeTools.done fi if [ -z "$BASH_DONE" ];then echo '===' echo 'Building BASH' echo '===' ... Claus -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
