|
From: Neil P. <np...@ex...> - 2003-05-19 23:26:44
|
Hi All,
I've used GPIB/HPIB a lot in the past (>5 years ago). Subsequently I've
done a lot of work with Linux (at SGI). I'm now trying to get the
Measurement Computing PCi Board to run with RH Linux 9.0 ... I'm getting
everything to work just fine for make etc. Even insmod/modprobe
installs the cb7210 module OK (checked using lsmod).
BUT, when I try ibtest I get the strangest result ...
> [root@localhost examples]# ./ibtest
> Do you wish to open a (d)evice or an interface (b)oard?
> (you probably want to open a device): d
> enter primary gpib address for device you wish to open [0-30]: 2
> trying to open pad = 2 on /dev/gpib0 ...
> Segmentation fault
I checked the code for the changes in cb7210 etc and I guess everything
is up to date in 3.1.93 ,,, so I think I must be doing something silly
... any body have any suggestions ?
Best Regards,
-Neil Phipps
Staff Physicist,
Exxim Computing Corporation,
3825 Hopyard Road, Suite #119,
Pleasanton, CA94588.
the gpib.conf file looks like this ...
> /***************************************************************************
> *
> * Syntax:
> *
> * interface { ... } starts new interface board section
> * device {...} device configuration
> *
> ***************************************************************************/
>
> /* This section configures the configurable driver characteristics
> * for an interface board, such as board address, and interrupt level.
> * minor = 0 configures /dev/gpib0, minor = 1 configures /dev/gpib1, etc.
> */
>
> interface {
> minor = 0 /* board index, minor = 0 uses /dev/gpib0, minor = 1 uses /dev/gpib1, etc. */
> board_type = "cbi_pci_accel" /* type of interface board being used */
> name = "optical" /* optional name, allows you to get a board descriptor using ibfind() */
> pad = 21 /* primary address of interface */
> sad = 0 /* secondary address of interface */
> timeout = T3s /* timeout for commands */
>
> eos = 0x0a /* EOS Byte, 0xa is newline and 0xd is carriage return */
> set-reos = yes /* Terminate read if EOS */
> set-bin = no /* Compare EOS 8-bit */
> set-xeos = no /* Assert EOI whenever EOS byte is sent */
> set-eot = yes /* Assert EOI with last byte on writes */
>
> /* settings for boards that lack plug-n-play capability */
> base = 21 /* Base io ADDRESS */
> irq = 0 /* Interrupt request level */
> dma = 0 /* DMA channel (zero disables) */
>
> /* pci_bus and pci_slot can be used to distinguish two pci boards supported by the same driver */
> /* pci_bus = 0 */
> /* pci_slot = 7 */
>
> master = yes /* interface board is system controller */
> }
>
> /* This is how you might set up a pcIIa board on /dev/gpib1, uncomment to use. */
> /*******************
> interface {
> minor = 1
> board_type = "pcIIa"
> pad = 0
> sad = 0
> timeout = T3s
>
> eos = 0x0a
> set-reos = yes
> set-bin = no
>
> base = 0x2e1
> irq = 7
> dma = 1
>
> master = yes
> }
> *********************/
>
> /* Now the device sections define the device characteristics for each device.
> * These are only used if you want to open the device using ibfind() (instead
> * of ibdev() )
> */
>
> device {
> minor = 0 /* minor number for interface board this device is connected to */
> name = "pico" /* device mnemonic */
> pad = 2 /* The Primary Address */
> sad = 0 /* Secondary Address */
>
> eos = 0xa /* EOS Byte */
> set-reos = no /* Terminate read if EOS */
> set-bin = no /* Compare EOS 8-bit */
> }
>
> device {
> minor = 0
> name = "scope"
> pad = 6
> sad = 0
> }
|
|
From: Frank M. H. <fm...@us...> - 2003-05-20 15:13:43
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 19 May 2003 06:26 pm, Neil Phipps wrote: > Hi All, > > I've used GPIB/HPIB a lot in the past (>5 years ago). Subsequently I've > done a lot of work with Linux (at SGI). I'm now trying to get the > Measurement Computing PCi Board to run with RH Linux 9.0 ... I'm gettin= g > everything to work just fine for make etc. Even insmod/modprobe > installs the cb7210 module OK (checked using lsmod). > > BUT, when I try ibtest I get the strangest result ... > > > [root@localhost examples]# ./ibtest > > Do you wish to open a (d)evice or an interface (b)oard? > > (you probably want to open a device): d > > enter primary gpib address for device you wish to open [0-30]: 2 > > trying to open pad =3D 2 on /dev/gpib0 ... > > Segmentation fault > > I checked the code for the changes in cb7210 etc and I guess everything > is up to date in 3.1.93 ,,, so I think I must be doing something silly > ... any body have any suggestions ? > Well, you should be using cbi_pci as the board_type instead of=20 cbi_pci_accel, unless you have the 1 megahertz version of the board. You= =20 still shouldn't get a segfault though. Would you send me the output of=20 'lspci -v'? - --=20 Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+ykbY5vihyNWuA4URAlrjAKCwiNhJFpiFqGaHnzJmOV74HUUKfQCePwJn S7JVdnum9pPSdaIsy8g/QYM=3D =3DqQDX -----END PGP SIGNATURE----- |
|
From: Neil P. <np...@ex...> - 2003-05-20 18:55:07
|
Hi Frank, Here's the lspci output ... it seems to make sense, it shows the two computer boards I have in the system, one is the 96 bit DIO card and the other is the GPIB card ... it should be the 1 MHz versioon, that's why I used cbi_pci_accel, but I did try it with the regular cbi_pci and got the same result ... using gdb it seems the segfault occurs almost before anything else happens ... I'll put in some breakpoints and send you more detailed info shortly, but for now, at least here's the lspci -v output ... Regards, -Neil >[root@localhost linux-gpib.3.1.93]# lspci -v >00:00.0 Host bridge: VIA Technologies, Inc. VT8375 [KM266] Host Bridge > Subsystem: VIA Technologies, Inc. VT8375 [KM266] Host Bridge > Flags: bus master, 66Mhz, medium devsel, latency 8 > Memory at e0000000 (32-bit, prefetchable) [size=64M] > Capabilities: [a0] AGP version 2.0 > Capabilities: [c0] Power Management version 2 > >00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] (prog-if 00 [Normal decode]) > Flags: bus master, 66Mhz, medium devsel, latency 0 > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 > Memory behind bridge: dfd00000-dfefffff > Prefetchable memory behind bridge: cfb00000-dfbfffff > Capabilities: [80] Power Management version 2 > >00:0a.0 Class ff00: Computer Boards: Unknown device 0006 > Flags: bus master, fast devsel, latency 32, IRQ 11 > I/O ports at ec00 [size=64] > I/O ports at e800 [size=16] > I/O ports at e400 [size=16] > >00:0b.0 Class ffff: Computer Boards: Unknown device 0054 (rev 02) (prog-if ff) > Subsystem: Computer Boards: Unknown device 0054 > Flags: medium devsel, IRQ 10 > Memory at dfffff80 (32-bit, non-prefetchable) [size=128] > I/O ports at e000 [size=128] > I/O ports at dc00 [size=32] > I/O ports at d800 [size=32] > >00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80) (prog-if 00 [UHCI]) > Subsystem: VIA Technologies, Inc. USB > Flags: bus master, medium devsel, latency 32, IRQ 10 > I/O ports at d400 [size=32] > Capabilities: [80] Power Management version 2 > >00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80) (prog-if 00 [UHCI]) > Subsystem: VIA Technologies, Inc. USB > Flags: bus master, medium devsel, latency 32, IRQ 11 > I/O ports at d000 [size=32] > Capabilities: [80] Power Management version 2 > >00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80) (prog-if 00 [UHCI]) > Subsystem: VIA Technologies, Inc. USB > Flags: bus master, medium devsel, latency 32, IRQ 11 > I/O ports at cc00 [size=32] > Capabilities: [80] Power Management version 2 > >00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) (prog-if 20 [EHCI]) > Subsystem: Giga-byte Technology GA-7VAX Mainboard > Flags: bus master, medium devsel, latency 32, IRQ 10 > Memory at dffffe00 (32-bit, non-prefetchable) [size=256] > Capabilities: [80] Power Management version 2 > >00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge > Subsystem: VIA Technologies, Inc. VT8235 ISA Bridge > Flags: bus master, stepping, medium devsel, latency 0 > Capabilities: [c0] Power Management version 2 > >00:11.1 IDE interface: VIA Technologies, Inc. VT82C586/B/686A/B PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) > Subsystem: VIA Technologies, Inc. VT8235 Bus Master ATA133/100/66/33 IDE > Flags: bus master, medium devsel, latency 32, IRQ 14 > I/O ports at fc00 [size=16] > Capabilities: [c0] Power Management version 2 > >00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97 Audio Controller (rev 50) > Subsystem: Giga-byte Technology GA-7VAX Onboard Audio (Realtek ALC650) > Flags: medium devsel, IRQ 11 > I/O ports at c800 [size=256] > Capabilities: [c0] Power Management version 2 > >00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) > Subsystem: Realtek Semiconductor Co., Ltd. RT8139 > Flags: bus master, medium devsel, latency 32, IRQ 11 > I/O ports at c400 [size=256] > Memory at dffffd00 (32-bit, non-prefetchable) [size=256] > Capabilities: [50] Power Management version 2 > >01:00.0 VGA compatible controller: S3 Inc. [ProSavageDDR K4M266] (prog-if 00 [VGA]) > Subsystem: Giga-byte Technology: Unknown device d000 > Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 10 > Memory at dfe80000 (32-bit, non-prefetchable) [size=512K] > Memory at d0000000 (32-bit, prefetchable) [size=128M] > Expansion ROM at dfe70000 [disabled] [size=64K] > Capabilities: [dc] Power Management version 2 > Capabilities: [80] AGP version 2.0 > >[root@localhost linux-gpib.3.1.93]# > Frank Mori Hess wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Monday 19 May 2003 06:26 pm, Neil Phipps wrote: > > >>Hi All, >> >>I've used GPIB/HPIB a lot in the past (>5 years ago). Subsequently I've >>done a lot of work with Linux (at SGI). I'm now trying to get the >>Measurement Computing PCi Board to run with RH Linux 9.0 ... I'm getting >>everything to work just fine for make etc. Even insmod/modprobe >>installs the cb7210 module OK (checked using lsmod). >> >>BUT, when I try ibtest I get the strangest result ... >> >> >> >>>[root@localhost examples]# ./ibtest >>>Do you wish to open a (d)evice or an interface (b)oard? >>> (you probably want to open a device): d >>>enter primary gpib address for device you wish to open [0-30]: 2 >>>trying to open pad = 2 on /dev/gpib0 ... >>>Segmentation fault >>> >>> >>I checked the code for the changes in cb7210 etc and I guess everything >>is up to date in 3.1.93 ,,, so I think I must be doing something silly >>... any body have any suggestions ? >> >> >> > >Well, you should be using cbi_pci as the board_type instead of >cbi_pci_accel, unless you have the 1 megahertz version of the board. You >still shouldn't get a segfault though. Would you send me the output of >'lspci -v'? > >- -- >Frank > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.6 (GNU/Linux) >Comment: For info see http://www.gnupg.org > >iD8DBQE+ykbY5vihyNWuA4URAlrjAKCwiNhJFpiFqGaHnzJmOV74HUUKfQCePwJn >S7JVdnum9pPSdaIsy8g/QYM= >=qQDX >-----END PGP SIGNATURE----- > > > >------------------------------------------------------- >This SF.net email is sponsored by: ObjectStore. >If flattening out C++ or Java code to make your application fit in a >relational database is painful, don't do it! Check out ObjectStore. >Now part of Progress Software. http://www.objectstore.net/sourceforge >_______________________________________________ >Linux-gpib-general mailing list >Lin...@li... >https://lists.sourceforge.net/lists/listinfo/linux-gpib-general > > > > |
|
From: Frank M. H. <fm...@us...> - 2003-05-20 22:11:06
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 20 May 2003 01:54 pm, Neil Phipps wrote: > Hi Frank, > > Here's the lspci output ... it seems to make sense, it shows the two > computer boards I have in the system, one is the 96 bit DIO card and th= e > other is the GPIB card ... it should be the 1 MHz versioon, that's why = I > used cbi_pci_accel, but I did try it with the regular cbi_pci and got > the same result ... using gdb it seems the segfault occurs almost befor= e > anything else happens ... I'll put in some breakpoints and send you mor= e > detailed info shortly, but for now, at least here's the lspci -v output > ... > It's unfortunate that Measurement Computing has assigned the same pci=20 device id to the 300k and 1M versions of their board, and they don't even= =20 appear to be compatible. During 'make config', you should turn on=20 debugging symbols in the library (which should help gdb), and debugging=20 output for the kernel modules (which will produce a lot of spam in your=20 kernel logs). Also, have you checked your kernel logs for a ksymoops=20 message when the segfault occurs?=20 - --=20 Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+yqdD5vihyNWuA4URAlVcAJ9eDRCtZWjaCMMwnfrtYWy0qtc6BwCfd/iz dlZBn73BdO9qQqrykEgwX5g=3D =3D5DnE -----END PGP SIGNATURE----- |
|
From: Neil P. <np...@ex...> - 2003-05-22 08:05:38
|
Hi Frank, I've traced my way through things until I found the Segfault ... it occurs during the 2nd malloc in yy_create_buffer in ibConFlex.c ... the malloc calls for 16386 bytes of memory, and _int_malloc dies ... so I changed the buffer size down to 1022 (+2 = 1024) and everything seems to run OK ... I'm thinking that it maybe a compiler issue ... RH 9.0 runs with gcc 3.2, so I tried gcc 3.3, but no success !!!! same issue ... which leads me to think it's an implementation issue in my system somewhere ... I also tried it with different systems ... the base system is a 1.3GHz Athlon with 128 MB RAM, but I got the same result with a twin 2200+ Athlon/2 GB RAM system and a 450 MHz PII with 512 MB RAM ... but they are all running RH 9.0 ... this leads me to ask ... What gcc version do you use, and what options are invoked ? Also, once it does run, the simple ibtest example gives the following ... any comments ? Regards, -Neil > Do you wish to open a (d)evice or an interface (b)oard? > (you probably want to open a device): d > Here ................... > enter primary gpib address for device you wish to open [0-30]: 6 > trying to open pad = 6 on /dev/gpib0 ... > gpib_yyrestart > yy_create > in yy_flex_alloc 40 > in yy_flex_alloc 1024 > yy_create > You can: > w(a)it for an event > change remote (e)nable line (system controller only) > send (i)nterface clear (system controller only) > get bus (l)ine status (board only) > (q)uit > (r)ead string > perform (s)erial poll (device only) > change (t)imeout on io operations > request ser(v)ice (board only) > (w)rite string > : e > Enter '1' to assert remote enable, or '0' to unassert: 1 > libgpib: ibsre error > gpib status is: > ibsta = 0x8100 < ERR CMPL > > iberr= 4 > EARG 4: Bad argument > > ibcnt = 0 > You can: > w(a)it for an event > change remote (e)nable line (system controller only) > send (i)nterface clear (system controller only) > get bus (l)ine status (board only) > (q)uit > (r)ead string > perform (s)erial poll (device only) > change (t)imeout on io operations > request ser(v)ice (board only) > (w)rite string > : i > gpib status is: > ibsta = 0x8100 < ERR CMPL > > iberr= 0 > EDVR 0: OS error > > ibcnt = 0 > You can: > w(a)it for an event > change remote (e)nable line (system controller only) > send (i)nterface clear (system controller only) > get bus (l)ine status (board only) > (q)uit > (r)ead string > perform (s)erial poll (device only) > change (t)imeout on io operations > request ser(v)ice (board only) > (w)rite string > : i > gpib status is: > ibsta = 0x8100 < ERR CMPL > > iberr= 0 > EDVR 0: OS error > > ibcnt = 0 > You can: > w(a)it for an event > change remote (e)nable line (system controller only) > send (i)nterface clear (system controller only) > get bus (l)ine status (board only) > (q)uit > (r)ead string > perform (s)erial poll (device only) > change (t)imeout on io operations > request ser(v)ice (board only) > (w)rite string > : s > serial poll result: 0xa4 > gpib status is: > ibsta = 0x100 < CMPL > > iberr= 4 > |
|
From: Frank M. H. <fm...@us...> - 2003-05-22 21:51:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 22 May 2003 03:04 am, Neil Phipps wrote: > Hi Frank, > > I've traced my way through things until I found the Segfault ... it > occurs during the 2nd malloc in yy_create_buffer in ibConFlex.c ... the > malloc calls for 16386 bytes of memory, and _int_malloc dies ... so I > changed the buffer size down to 1022 (+2 =3D 1024) and everything seems= to > run OK ... I'm thinking that it maybe a compiler issue ... RH 9.0 runs > with gcc 3.2, so I tried gcc 3.3, but no success !!!! same issue ... > which leads me to think it's an implementation issue in my system > somewhere ... I also tried it with different systems ... the base syste= m > is a 1.3GHz Athlon with 128 MB RAM, but I got the same result with a > twin 2200+ Athlon/2 GB RAM system and a 450 MHz PII with 512 MB RAM ... > but they are all running RH 9.0 ... this leads me to ask ... What gcc > version do you use, and what options are invoked ? I use gcc 2.95.4 and 3.2.3. Apparently, this kind of problem is due to=20 heap corruption. You might try playing around with mcheck() to see if yo= u=20 can find any problems. I'll try it myself later, but I might have less=20 luck as I've never had the problems you are seeing. The problem might=20 also be with flex, since ibConfLex.c is auto-generated by flex (I use=20 2.5.4). > > Also, once it does run, the simple ibtest example gives the following > ... any comments ? > The errors are normal. You are trying to do board operations (setting th= e=20 remote enable and interface clear lines) with a device descriptor. - --=20 Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+zT/f5vihyNWuA4URAkeIAJ4rGGzi1N/6XvHJll+zBFyFJQp2oQCdFcBv o2lbCraVqWs7Hcdvfr6VhGU=3D =3DbV/o -----END PGP SIGNATURE----- |