Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!ira.uka.de!smurf!flatlin!tpki!oski!schlut From: schlut@oski.toppoint.de (Olaf Schlueter) Newsgroups: comp.os.minix Subject: Re: Minix ST 1.5 printer driver problems Message-ID: <35@oski.toppoint.de> Date: 25 Apr 91 16:01:38 GMT References: <30@oski.toppoint.de> Lines: 32 meulenbr@cst.prl.philips.nl (Frans Meulenbroeks) writes: >I've seen reports about bad printer problems before. >Since I don't have a parallel printer, I cannot test these. >However someone reported that this is due to the fact that the >winchester task uses op to much stack. >Try to change the definition of WINCH_STACK to >#define WINCH_STACK (3*SMALL_STACK/2) The winchester task indeed uses too much stack, that's true. It does so since patch 1 to Minix 1.5 ST, when the winchester task learned about extended partition schemes. During the initialization of the winchester task, at least one, if a XGM partition is encountered, two struct's with size 512 Bytes and auto storage class are used, causing the winchester task to creep into the bottom of the printer's task stack. You won't notice it, until you try to print something to /dev/lp. Since I got patch #1 out of the dump of old minix articles, I thought that this had been reported earlier, but obviously it wasn't. So if anyone has problems using his line printer connected to the parallel port after applying patch #1 (which did not touch stprint.c), have a look at st_wini.c, there are two big struct's hi or so. Change their storage class to static. (or increase the stacksize like frans suggests, that should work either). On my system, the task stack overflow caused the system to crash with a kernel trap panic. But this is not the solution to my reported printer problem. -- -- Olaf Schlueter, Sandkuhle 4-6, 2300 Kiel 1, Germany, Toppoint Mailbox e.V. schlut@oski.toppoint.de, olaf@tpki.toppoint.de, ...!unido!tpki!olaf