Re: [Sheflug] pts/x

[Guennadi Liakhovetski <nospam [at] ragingbull.com>]

On Mon, 5 Mar 2001 home [at] alexhudson.com wrote:

> On Mon, Mar 05, 2001 at 12:38:17AM +0000, Guennadi Liakhovetski wrote:
> > Ok, I did have a lot of times, when an ssh session (via a firewall, which
> > doesn't matter here, does it?) was cut (ic24 disconnects you every hour),
> > but I am sure this happened not only to pts/2. And remember - there's NO
> > '2' in /dev/pts/... What else keeps track of pts's? some static array in
> > the kernel?...
> 
> Yes, it would happen to all the pts', not just two, and even if locked
> I would expect to see a pts/2. Weird. As for the data structure, no,
> it's not an array, it's dynamic. It may very well have been an array
> at some point - a lot of kernel structures were, like the mount list
> in 2.0, but most stuff is now dynamic.

Well, by 'static' I meant not allocation method (as opposed to 'dynamic',
should rather have used a generic term like 'list' than 'array') but the
static storage class... Is there one? Can't think of another
explanation...

> The only reason (code-wise) that allocating pts/2 would fail would be
> if init_dev() on that device failed - the other option is that makedev
> failed, which would be pretty weird. It could be worth putting a
> printk() in the main allocation loop, to print out something when it
> considers the case pts/2 - if init_dev() is failing, you'll expect an
> error code (like -ENODEV), which could give you more information.

As I wrote in another post - pts/2 got blocked after an xterm (rxvt) crash
- not over ssh, I did rlogin, rxvt &. Putting printk means rebooting the
system, and then, of course, this particular instance of a problem with
pts/2 would disappear, but quite possible that I would be able to
reproduce it by crashing rxvt in the same way as before. I think I wrote
earlier - it went like this:
1) open rxvt, pts/2 appears, who has extra line (I didn't check, but I
assume)
2) rxvt crashes, pts/2 disappears, line in who stays, pts/2 blocked
3) I re-initialize /var/run/utmp, line in who goes, pts/2 still blocked
(present state)

On another occasion pts/4 got blocked in exactly the same way, but before
I re-initialized utmp, one of terminals got associated with pts/4 (then
who produced 2 lines with pts/4!), and, when I closed that other session
with pts/4 both lines from who disappeared and pts/4 got unlocked! VERY
weird, to say the least:-) Before putting printk's etc., I probably will
enquire on the linux-kernel mailing list - maybe they know:-)

> > pretty well familiar with the linux kernel... I want to port a piece of
> > code from 2.0.39 to 2.2.x / 2.4.x (it was just lost...). But I can't
> 
> Yes, I could have a go if you like. Depends how big a project and how
> evil a piece of code it is tho' :))

Great! hope it's not too evil:-) The story is: I borrowed a P75 from the
University to take home, installed Linux on it, and at some stage I
noticed that I can't enable IDE-DMA (Bus-Mastering). I spent _A_LOT_ of
time trying to figure out what the problem was, eventually, Andre Hedrick
suggested that I try 2.0.39 - and yes, it worked there... So, my current
understanding of the problem is: current kernels (2.2.x and 2.4.x) fail to
1) approve this hardware as DMA-ready; 2) (after you disable these tests)
find the DMA-base address. What I did then - I simply hard-coded DMA-base
values found by 2.0.39 into 2.2.18 / 2.4.0 - and now it is working... But
you understand - this is dirty and breaks the kernel for other chipsets.
BTW, mine is Intel 430FX (Triton) aka PIIX. Looks like it is some very
rare version of the chipset:-) Ok, I can put a check - only use this
address for this particular PCI_VENDOR_ID and PCI_DEVICE_ID, or add some
Configuration option, or kernel parameter... But - I think - the clean way
to do this would be to port the 2.0.39 algorithm to be used if everything
else fails. The algorithm, to the best of my understanding, is some sort
of scanning of an address range checking for a valid PCI_BIOS (or IDE...
can't quite remember) signature... Andre did write a patch for this,
writing a BMIBA value - it didn't work. Then he became far too busy, and
when he heard that I got it (somehow) working - he stopped his efforts on
this issue:-) Maybe the idea behind Andre's patch is correct and we'll
just be able to fix it?

So, shall we give it a go? You can reply to me directly to gvlyakh at
ragingbull.com.

Thanks
Guennadi
___

Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: G.Liakhovetski [at] sheffield.ac.uk


---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.