Dotaz: parport0

[ubka7617]

Dobry den,

na pc som do nedavna pouzival debian etch ktory som preinstaloval na debian squeeze. Od vtedy ked tlacim na tlaciaren cez parallelny port /dev/parport0 aby ola spatna komunikacia s tlaciarnou tak je komunikacia ovela pomalsia ako na starom debiane.

nestretli ste sa s niecim ze bol pomaly parallelny port v debiane ?

dakujem za kazdu radu

---

---

Odpovědi

[hajoucha]

hm, a určitě to vázna na parportu? Není to třeba změnou filtrů nebo tak něco?

[ubka7617]

zrejme nie lebo mam vsetko ako na etch akurat mam novsi modul na parport_pc

ake filtre ?

[e.lisak]

Opravdu musíte používat /dev/parportX? (ten je určen na jiné věci, než běžné tiskárny - na ty bude výrazně pomalejší)

K tiskárně bych čekal spíš /dev/lpX a vhodný (nejlépe obousměrný) režim.

[ubka7617]

pouzivam to na tlac cez javapos z javy. Cez /dev/lp0 dava chybu: The device communications channel could not be opened, chech the device and retry.

[Pavel Stárek]

Nevím úplně přesně jak je to v Debianu, ale třeba ve Fedoře musím mít uživatele ve skupině lp . A pak na toto zařízení může zapisovat a číst z něj.

[ubka7617]

je to tak aj v debiane ak by nebol pridany by nemohol tlacit vobec takto tlaci velmi pomaly, hlavne pri nahravani loga

[pc2005]

Taky by teoreticky mohly být vypnutý ty zrychlující featury jako ECP a EPP (ono i samotny DMA + fifo dost ulehčí). Podívej se kdyžtak v dmesgu na hlášky modulu (pokud bys to házel sem, tak ještě můžeš přihodit výpis z lsmod). Jinak pokud jsou ty featury vypnutý v BIOSu, tak je modul nenajde.

[ubka7617]

vystup z lsmod:

Module                  Size  Used by
usblp                   7899  0
joydev                  6739  0
sg                     19937  0
st                     26908  0
sr_mod                 10770  0
ide_gd_mod             17163  0
ide_cd_mod             21080  0
ide_core               59614  2 ide_gd_mod,ide_cd_mod
cdrom                  26435  2 sr_mod,ide_cd_mod
ppdev                   4058  0
lp                      5570  0
loop                    9769  0
snd_intel8x0           19595  0
snd_ac97_codec         79152  1 snd_intel8x0
ac97_bus                 710  1 snd_ac97_codec
snd_pcm                47222  2 snd_intel8x0,snd_ac97_codec
i915                  223022  2
drm_kms_helper         18569  1 i915
snd_seq                35463  0
drm                   112053  3 i915,drm_kms_helper
i2c_algo_bit            3493  1 i915
video                  14605  1 i915
output                  1204  1 video
snd_timer              12270  2 snd_pcm,snd_seq
snd_seq_device          3673  1 snd_seq
rng_core                2178  0
parport_pc             15799  1
snd                    34415  6 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_seq,snd_timer,snd_seq_device
parport                22554  3 ppdev,lp,parport_pc
i2c_i801                6462  0
i2c_core               12787  5 i915,drm_kms_helper,drm,i2c_algo_bit,i2c_i801
soundcore               3450  1 snd
psmouse                44837  0
dcdbas                  3892  0
pcspkr                  1207  0
evdev                   5609  9
snd_page_alloc          5045  2 snd_intel8x0,snd_pcm
serio_raw               2916  0
button                  3598  1 i915
processor              26327  0
ext3                   94396  6
jbd                    32401  1 ext3
mbcache                 3762  1 ext3
sd_mod                 26013  8
crc_t10dif              1012  1 sd_mod
usbhid                 28016  0
hid                    50909  1 usbhid
ata_generic             2247  0
uhci_hcd               16057  0
thermal                 9206  0
ata_piix               17736  7
tg3                    95865  0
ehci_hcd               28689  0
thermal_sys             9378  3 video,processor,thermal
libata                115869  2 ata_generic,ata_piix
scsi_mod              105001  5 sg,st,sr_mod,sd_mod,libata
libphy                 11638  1 tg3
usbcore                99321  5 usblp,usbhid,uhci_hcd,ehci_hcd
nls_base                4541  1 usbcore

[ubka7617]

oot@s-3660-01:~# dmesg |grep parport
[    7.044400] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
[   27.250699] lp0: using parport0 (interrupt-driven).

[pc2005]

Tak to je ten nejpomalejší mód, ten snad umí jen obousměrnou komunikaci a při porovnání s mou konfigurací

parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]

asi ani nebude umět FIFO ani DMA a pojede tak maximálně ~100kBps. Máš nějakou novou tiskárnu, nebo něco ve stylu jehličkárny? Ideální by bylo porovnat výpisy u obou jader, zda se opravdu liší.

BTW Proč máš zavedenej modul pro usb tiskárnu (usblp)?

[ubka7617]

usb tlacaren mam klasicku laserovu tlaciaren a na paralellnom porte mam thermo tlaciaren od Staru. Vypis z dmesg je rovnaky ako na debian etch a tam mi to slapalo rychlo az po preinstalovani na squeeze sa tlac na parport rapidne znizila.

[pc2005]

Jestli je výpis z dmesgu ohledně modulu parport_pc stejnej, tak bude problém jinde (osobně mám i za to, že se v parportu toho moc neděje). Bohužel nevím jaká je konfigurace obou jader (soubor config) stejně jako verze, namátkové hledání na strankách debianu nic neobjevilo. Ideální by ale bylo porovnat zdrojáky obou verzí jader (*.c z drivers/parport/ s důrazem na parport.c a parport_pc.c).

Co jsem se se koukal, tak některé tiskárny můžou využívat usblp nebo userspace knihovnu. Je možný, že to třeba koliduje a přenáší se to i na tu parport. Zkoušels tisknout i bez té USB? Nebo kdyžtak před tiskem odeber lp a ppdev (když píšeš, že lp nepoužíváš). Vytvoří se přípojný bod pro tu USB tiskárnu (třeba by mohlo kolidovat /dev/lp0 a /dev/lp1)?

[ubka7617]

Příloha:

• config-2.6.32-5-686 (111135 bytů)

posielam config subor pre jadro je to standardtne jadro nekompilovane z debian squeeze. Pre usb tlacku sa mi vytvara /dev/usb/lp1

[pc2005]

A zbytek systému (user level ovladače, knihovny, aplikace tisku) je updatovanej na squeeze? Poslední verze jádra etche byla jaká?

Konfigurace je skoro OK (byť je u parportu plno zbytečností s nestandardními porty) až na fakt, že v tom konfiguráku máš zřejmě vypnutý FIFO a DMA pro parport (ale zase podle stejnýho výpisu z dmesg by vyplývalo, že to nebylo zapnut ani na etchi). Jestli je ta konfigurace u obou jader stejná a při bootu maj stejný výpis, tak bude chyba nejspíš nekde jinde (chtělo by to možná porovnat zdrojáky obou jader).

Co myslíš zde tím akorát? Moduly novýho jádra přece nejdou použít ve starém jádru (rozhodně ne bezpečně).

Jinak můžeš zkusit při načtení parport_pc nastavit parametr "verbose_probing" s nenulovou hodnotou. Nebo si pohrát s parametrem ze souboru /proc/sys/dev/parport/parport0/spintime, kde by snad měla jít nastavovat prodleva (nikdy jsem si s tím ale úspěšně nehrál).

Ta tiskárna asi nebude standardní ne (když je termo a používá se s javaposem)? Jde na ní tisknout i normálně z OS? Jestli máš možnost starého jádra, tak můžeš ještě zkusit, zda to dělá i s jiným typem LPT tiskárny.

Jinak do toho ECP/EPP/Compat bych šel. Mohlo by to aspoň trochu pomoct.

[ubka7617]

nakompiloval som jadro 3.4.6

dmesg |grep parport
parport_pc 00:06: reported by Plug and Play ACPI
parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA]

 

a je to este pomalsie

CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_SERIAL=y
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_PC_PCMCIA is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y

[pc2005]

Má ta tiskárna (termoprinter a javapos, to nebude asi normální tiskárna na A4, že?) vůbec standardní komunikaci? Co ostatní věci z mýho minulýho postu, jak se projevili? Ještě můžeš zkusit ve zdrojákách toho 3.4.6 odkomentovat v drivers/parport/*.c makro DEBUG a ono to pak bude vypisovat do dmesgu všechny přenosy.

Zajímavý, jestli to jede ještě pomalejc než v předchozí verzi jádra, přenos dat by totiž měl být nezávislý na procesoru, prostě se jen vezme blok paměti a ten se DMA postupně překopíruje do tiskárny. Maximální rychlost určuje tiskárna. Jakej je přesnej typ? Že bych si u výrobce našel datasheet.

P.S. A když vyhodíš všechno kromě

CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m

A disabluješ v BIOSu, bude to stejně rychlý jako squeeze kernel?

[ubka7617]

tlaciaren je star tsp 654C

[pc2005]

A zkoušel jsi tisknout i přes CUPS?

Jinak na stránkách u výrobce je driver pro javapos i pro CUPS a hlavně tam jsou zajímavý dokumentace. U CUPS varianty (resp příkazu lpr) je například parametr "Print Speed" u javapos driveru je v konfiguráku "ioTimeoutMillis". Ale jestli stačí změnit jádro při bootu a pak to jde jinak, tak to asi tímhle nebude.

Co se týče komunikace, tak by tiskárná měla umět po nastavení DIP switchů ESC/POS, což je klasický protokol jako třeba u jehličkových tiskáren. Druhý protokol je nějakej Star nevím jestli bude kompatibilní (a nevím který máš nastavený). Jinak vyplnění /dev/parport do javapos konfigurace je správný, je to i v manuálu.

Kdyžtak si zkus pohrát s nastavením toho CUPSu nebo javaposu, další nápady už bohužel nemám (málo informací) .

[pc2005]

P.S. Ještě kdyžtak link na ty datasheety a drivery.

[pavelsefranek]

Aktuálně řeším úplně stejný problém. U mě se jedná o jehličkovou tiskárnu STAR SP 742. Překvapivě jede perfektně rychle bez jakýchkoli záškubů pouze na systémech typu Red Hat (Centos 6.3 a Fedora 17), kde parport hlásí

parport0: PC-style at 0x278 (0x678), irq 5 [PCSPP,TRISTATE]

Na ostatních systémech (zkoušeno na Ubuntu 12.04 a openSUSE 12.2), kde parport_pc hlásí

parport0: PC-style at 0x278 (0x678), irq 5, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]

tiskárna tiskne velice pomalu a během tisku nepravidelně, zaškubává se.

To o čem mluvil kolega, že tiskne přímo na /dev/parport0, tak tímto způsobem lze tisknout pouze pomocí k tiskárně přiloženého softwaru JavaPOS, který má pravděpodobně svůj vlastní ovladač na přímý přístup k paralelnímu portu (tedy nemusí používat vrstvu /dev/lp0). Program JavaPOS ostatně ani na /dev/lp0 tisknout neumí. Tisk prostřednictvím JavaPOS na /dev/parport0 funguje rychle a bez záškubů i na systémech jako je Ubuntu či openSUSE.

Vypadá to, že problém tedy bude v tom, že jádra Ubuntu a openSUSE mají povolené FIFO, zatímco systému Red Hat ho mají zakázané.

Byl bych rád, kdybyste se ještě k tématu vyjádřili, zda se povedl problém vyřešit. Ubuntu bych rád používal, ale nefunkčnost této tiskárny mě drží na CentOSu. Pokud by byly jakékoli připomínky, či další cenné rady a zkušenosti, prosím pomozte mi chybu v jádře Ubuntu vyřešit. Chybu jsem také nahlásil na Lauchpad (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/339752) a velice bych rád, kdyby se vyřešila.

Děkuji

[pavelsefranek]

Tak chyba vyřešena. Překompiloval jsem kernel se zakázaným FIFO a tiskárna jede jako po másle. Pokud máte Ubuntu, měla by být vydána oprava jak pro 12.04 LTS, tak pro nejnovější 12.10.