sd8686 linux system hang: not always

sd8686 linux system hang: not always

[Benoît Vaillant]

Hi list,

It seems my previous message for libertas-dev didn't make its ways
through, so resending it... Appologies if it did in any way and for
multiple receptions if any :/

Here are a few notes, to try to isolate the issue(s?) regarding this
problem.

/*
Just a bit of context information:
I'm using an MID (quite close to an Aigo, although bios differs,
probably some hardware too, yet I've not checked much on that). I'm
trying to use my Marvell card to get wifi access on a debian
installation. The other OS installed (midinux) successfully gets a
connection using the 8686_v9 mobilin driver, so I'd not go for any
hardware issue. This driver failing to compile 'out of the box' on
fresh kernels, I thought getting the libertas module working would be
a better way to get through.
*/

I had the same kernel hang issue as reported earlier on this list[1]
and can also confirm the reload issue[2] still seems to be here,
although I'm not really bothered by that for the moment and didn't
take any time at assessing it.

I did a few attempts at getting associated with an AP, initially
unsuccessfully getting a hang, my latest attempts leading to a better
result (no association, yet no hang! :) ).

I've tried both 8.73.7.p3 and 9.70.3.p24 versions of the firmware (and
the one provided by midinux, which I highly suspect to be a mere
8.73.7.p3). In my latest attempts, I focused only on the 8.73.7.p3
since it gave good results using iwlist scannig: I could list the
available APs fine.

Now, with the attempts I did, using a kernel 2.6.31-rc5, I used to
hang. Using some manually inserted printk()s, it lead me from the
libertas driver to mmc, esp. in drivers/mmc/core.c the
mmc_wait_for_req(...) function. It was done without mmc debugging
messages, with libertas debugging symbols activated but not printed
out.

From there on, I switched to the wireless git[3] in order to be able
to provide more convinient patches if needed. I immediately patched it
against the attached proposal from last thread[4], adapting it due to
compile issues (see below). I also gave a quick try at Philip's
proposal[5], which didn't seem to work, unfortunately.

about the patch: I didn't adapt it as proposed latter on in the thread
by setting 0 values, but by reinserting the "old"
cmd_ds_802_11_get_log log structure. Wrong thing?

The good news using this kernel was that I wasn't always stuck in a
hang: listing the APs works, connecting to an AP using WPA & french
bands failed, yet without hanging (here, I had MMC & libertas
debugging messages).

The bad news is I can reproduce the hang using these sources quite
easily if I do, say: an association request, followed by an iwconfig
to check if the association was done *before* all the attempts were
done. The attempts I did using iwconfig once the previous one
timed-out were successfull.

This leads me to think there are in fact two issues:
 - an association issue (at least in France). Maybe not much of a
   problem? I might even be the one doing the wrong thing, not the
   kernel :)
 - an issue when accessing the card (race condition?), which could be
   more subtle to handle.

Using the fresh 2.6.31-rc6 kernel.org release, with MMC & libertas
debugging messages on, I still can do an association request without
getting neither a hang, nor an association. So maybe one of the race
issues that are patched in it do solve part of this problem. Yet,
running several AP association requests does hang.

I'd be glad to do more testing and provide usefull information. Any
idea(s) on which track(s) I should now follow and how I can help you
solve this issue?

Thanks,

-- 
Benoît

[1] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002487.html
[2] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002510.html
[3] git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
[4] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002496.html
[5] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002494.html

Re: sd8686 linux system hang: not always

[Dan Williams]

On Wed, 2009-08-19 at 20:56 +0200, Benoît Vaillant wrote:
> Hi list,
> 
> It seems my previous message for libertas-dev didn't make its ways
> through, so resending it... Appologies if it did in any way and for
> multiple receptions if any :/
> 
> Here are a few notes, to try to isolate the issue(s?) regarding this
> problem.
> 
> /*
> Just a bit of context information:
> I'm using an MID (quite close to an Aigo, although bios differs,
> probably some hardware too, yet I've not checked much on that). I'm
> trying to use my Marvell card to get wifi access on a debian
> installation. The other OS installed (midinux) successfully gets a
> connection using the 8686_v9 mobilin driver, so I'd not go for any
> hardware issue. This driver failing to compile 'out of the box' on
> fresh kernels, I thought getting the libertas module working would be
> a better way to get through.
> */
> 
> I had the same kernel hang issue as reported earlier on this list[1]
> and can also confirm the reload issue[2] still seems to be here,
> although I'm not really bothered by that for the moment and didn't
> take any time at assessing it.
> 
> I did a few attempts at getting associated with an AP, initially
> unsuccessfully getting a hang, my latest attempts leading to a better
> result (no association, yet no hang! :) ).
> 
> I've tried both 8.73.7.p3 and 9.70.3.p24 versions of the firmware (and
> the one provided by midinux, which I highly suspect to be a mere
> 8.73.7.p3). In my latest attempts, I focused only on the 8.73.7.p3
> since it gave good results using iwlist scannig: I could list the
> available APs fine.
> 
> Now, with the attempts I did, using a kernel 2.6.31-rc5, I used to
> hang. Using some manually inserted printk()s, it lead me from the
> libertas driver to mmc, esp. in drivers/mmc/core.c the
> mmc_wait_for_req(...) function. It was done without mmc debugging
> messages, with libertas debugging symbols activated but not printed
> out.

Just for context, what SDIO controller are you using on this platform?

Dan

> From there on, I switched to the wireless git[3] in order to be able
> to provide more convinient patches if needed. I immediately patched it
> against the attached proposal from last thread[4], adapting it due to
> compile issues (see below). I also gave a quick try at Philip's
> proposal[5], which didn't seem to work, unfortunately.
> 
> about the patch: I didn't adapt it as proposed latter on in the thread
> by setting 0 values, but by reinserting the "old"
> cmd_ds_802_11_get_log log structure. Wrong thing?
> 
> The good news using this kernel was that I wasn't always stuck in a
> hang: listing the APs works, connecting to an AP using WPA & french
> bands failed, yet without hanging (here, I had MMC & libertas
> debugging messages).
> 
> The bad news is I can reproduce the hang using these sources quite
> easily if I do, say: an association request, followed by an iwconfig
> to check if the association was done *before* all the attempts were
> done. The attempts I did using iwconfig once the previous one
> timed-out were successfull.
> 
> This leads me to think there are in fact two issues:
>  - an association issue (at least in France). Maybe not much of a
>    problem? I might even be the one doing the wrong thing, not the
>    kernel :)
>  - an issue when accessing the card (race condition?), which could be
>    more subtle to handle.
> 
> Using the fresh 2.6.31-rc6 kernel.org release, with MMC & libertas
> debugging messages on, I still can do an association request without
> getting neither a hang, nor an association. So maybe one of the race
> issues that are patched in it do solve part of this problem. Yet,
> running several AP association requests does hang.
> 
> I'd be glad to do more testing and provide usefull information. Any
> idea(s) on which track(s) I should now follow and how I can help you
> solve this issue?
> 
> Thanks,
> 
> -- 
> Benoît
> 
> [1] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002487.html
> [2] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002510.html
> [3] git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
> [4] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002496.html
> [5] http://lists.infradead.org/pipermail/libertas-dev/2009-June/002494.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: sd8686 linux system hang: not always

[Benoît Vaillant]

[-- Attachment #1.1: Type: text/plain, Size: 1215 bytes --]

On Wed, Aug 19, 2009 at 02:39:57PM -0500, Dan Williams wrote:
> On Wed, 2009-08-19 at 20:56 +0200, Benoît Vaillant wrote:
> > /*
> > Just a bit of context information:
> > I'm using an MID (quite close to an Aigo, although bios differs,
> > probably some hardware too, yet I've not checked much on that). I'm
> > trying to use my Marvell card to get wifi access on a debian
> > installation. The other OS installed (midinux) successfully gets a
> > connection using the 8686_v9 mobilin driver, so I'd not go for any
> > hardware issue. This driver failing to compile 'out of the box' on
> > fresh kernels, I thought getting the libertas module working would be
> > a better way to get through.
> > */
> > <snip>
> 
> Just for context, what SDIO controller are you using on this platform?

Sure, i can provide that!

lspci claims i's an:
00:e1.0 SD Host controler: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #1 (rev 06)
00:e1.1 SD Host controler: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #2 (rev 06)

Complete `lspci -vvv` is attached.

Could this lead to anything already known which i have might missed?

Thanks,

-- 
Benoît


[-- Attachment #1.2: lspci-vvv.txt --]
[-- Type: text/plain, Size: 7933 bytes --]

00:00.0 Host bridge: Intel Corporation Device 8101 (rev 06)
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0

00:02.0 VGA compatible controller: Intel Corporation Device 8109 (rev 06) (prog-if 00 [VGA controller])
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 7
	Region 0: Memory at c8080000 (32-bit, non-prefetchable) [size=512K]
	Region 1: I/O ports at 1800 [size=8]
	Region 2: Memory at d0000000 (32-bit, non-prefetchable) [size=128M]
	Region 3: Memory at c8000000 (32-bit, non-prefetchable) [size=128K]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] Vendor Specific Information <?>
	Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000

00:1a.0 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB Client Controller (rev 06) (prog-if 80 [Unspecified])
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 255
	Region 0: Memory at c8020000 (32-bit, non-prefetchable) [disabled] [size=4K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

00:1b.0 Audio device: Intel Corporation System Controller Hub (SCH Poulsbo) HD Audio Controller (rev 06)
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 255
	Region 0: Memory at c8024000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
			ExtTag- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM L0s Enabled; Disabled- Retrain- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
	Capabilities: [100] Virtual Channel <?>
	Capabilities: [130] Root Complex Link <?>

00:1d.0 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB UHCI #1 (rev 06) (prog-if 00 [UHCI])
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 4: I/O ports at 1820 [size=32]
	Kernel driver in use: uhci_hcd

00:1d.1 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB UHCI #2 (rev 06) (prog-if 00 [UHCI])
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 19
	Region 4: I/O ports at 1840 [size=32]
	Kernel driver in use: uhci_hcd

00:1d.2 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB UHCI #3 (rev 06) (prog-if 00 [UHCI])
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin C routed to IRQ 18
	Region 4: I/O ports at 1860 [size=32]
	Kernel driver in use: uhci_hcd

00:1d.7 USB Controller: Intel Corporation System Controller Hub (SCH Poulsbo) USB EHCI #1 (rev 06) (prog-if 20 [EHCI])
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin D routed to IRQ 21
	Region 0: Memory at c8021000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Debug port: BAR=1 offset=00a0
	Kernel driver in use: ehci_hcd

00:1e.0 SD Host controller: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #1 (rev 06) (prog-if 01)
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 22
	Region 0: Memory at c8021400 (32-bit, non-prefetchable) [size=256]
	Kernel driver in use: sdhci-pci

00:1e.1 SD Host controller: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #2 (rev 06) (prog-if 01)
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 20
	Region 0: Memory at c8021800 (32-bit, non-prefetchable) [size=256]
	Kernel driver in use: sdhci-pci

00:1f.0 ISA bridge: Intel Corporation System Controller Hub (SCH Poulsbo) LPC Bridge (rev 06)
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Kernel driver in use: isch_smbus

00:1f.1 IDE interface: Intel Corporation System Controller Hub (SCH Poulsbo) IDE Controller (rev 06) (prog-if 80 [Master])
	Subsystem: COMPAL Electronics Inc Device 002e
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
	Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
	Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [size=8]
	Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [size=1]
	Region 4: I/O ports at 1810 [size=16]
	Kernel driver in use: pata_sch


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: sd8686 linux system hang: not always

[Dan Williams]

On Thu, 2009-08-20 at 22:40 +0200, Benoît Vaillant wrote:
> On Wed, Aug 19, 2009 at 02:39:57PM -0500, Dan Williams wrote:
> > On Wed, 2009-08-19 at 20:56 +0200, Benoît Vaillant wrote:
> > > /*
> > > Just a bit of context information:
> > > I'm using an MID (quite close to an Aigo, although bios differs,
> > > probably some hardware too, yet I've not checked much on that). I'm
> > > trying to use my Marvell card to get wifi access on a debian
> > > installation. The other OS installed (midinux) successfully gets a
> > > connection using the 8686_v9 mobilin driver, so I'd not go for any
> > > hardware issue. This driver failing to compile 'out of the box' on
> > > fresh kernels, I thought getting the libertas module working would be
> > > a better way to get through.
> > > */
> > > <snip>
> > 
> > Just for context, what SDIO controller are you using on this platform?
> 
> Sure, i can provide that!
> 
> lspci claims i's an:
> 00:e1.0 SD Host controler: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #1 (rev 06)
> 00:e1.1 SD Host controler: Intel Corporation System Controller Hub (SCH Poulsbo) SDIO Controller #2 (rev 06)
> 
> Complete `lspci -vvv` is attached.
> 
> Could this lead to anything already known which i have might missed?

Well, besides the fact that the Poulsbo SDHC driver hasn't actually
passed review for the kernel yet...  That doesn't mean the Poulsbo
driver isn't a fine driver, but if Pierre hasn't acked it, I don't
really trust it.  The largest # of problems people have had with
Libertas SDIO have been with the host controller with things like
transfer widths, clocking, interrupt vs. polled mode, chunk size, etc.
When the SDHC driver and hardware they are using actually starts working
well, then libertas actually starts working well.

So I don't mean to brush you off, but we know the chip works pretty well
with the Ricoh line (which I'm typing this on right now with an sd8686)
and a few other embedded-type controllers.  So I'd start diving down
into the SDHC driver code for Poulsbo and try to figure out what's going
on there and in the MMC layer.

Dan

Re: sd8686 linux system hang: not always

[Benoît Vaillant]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

Hi,

On Fri, Aug 21, 2009 at 08:04:16AM -0500, Dan Williams wrote:
> Well, besides the fact that the Poulsbo SDHC driver hasn't actually
> passed review for the kernel yet... 

And other parts of Poulsbo drivers were removed from -at least-
debian, for the xorg part of it. I had that in mind.

> That doesn't mean the Poulsbo driver isn't a fine driver, but if
> Pierre hasn't acked it, I don't really trust it.  The largest # of
> problems people have had with Libertas SDIO have been with the host
> controller with things like transfer widths, clocking, interrupt
> vs. polled mode, chunk size, etc.  When the SDHC driver and hardware
> they are using actually starts working well, then libertas actually
> starts working well.

Ok. I'll check on parameters when I get spare time. I did consider
such things could be part (all? :) ) of the issue.

Pointers welcomed, if any other than browsing the web!

> So I don't mean to brush you off, but we know the chip works pretty well
> with the Ricoh line (which I'm typing this on right now with an sd8686)
> and a few other embedded-type controllers.  So I'd start diving down
> into the SDHC driver code for Poulsbo and try to figure out what's going
> on there and in the MMC layer.

Hehe, no worry, I know the chip works fine under midinux. Yet
compiling such working drivers would either lead me to revert to an
older kernel version (and not provide testing with newer ones, thus)
or adapt the marvell driver to newer kernel, task which I'm rather not
sure to be able to carry by some quite good amount of time :)

You didn't brush me off, I wasn't expecting a straight working
solution :)

TFYA,

-- 
Benoît

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]