Linux-Development-Sys Digest #751, Volume #8     Sat, 26 May 01 13:13:12 EDT

Contents:
  scsi tape robotic changer question ("Gene Heskett")
  /ttyS0 (Katie Mueller)
  Re: Kernel (mal)function after harmless driver Segmenttion Error (Kasper Dupont)
  Re: Win NT boot and Lilo boot (Kasper Dupont)
  Re: ext2 limitations ("Karl Heyes")
  Re: Kernel (mal)function after harmless driver Segmenttion Error ("Norm Dresner")
  Help!! ("psy")
  Re: C++ linux server to java client: connection problem (Mike Hebert)
  Re: C++ linux server to java client: connection problem (VRETOS Nicholas)

----------------------------------------------------------------------------

Date: 25 May 2001 23:8:26 -0500
From: "Gene Heskett" <[EMAIL PROTECTED]>
Subject: scsi tape robotic changer question

Hi Bill;

You sound like you're familiar with devices, and I have a device
problem.  I just bought a new Seagate 4586 for backing things up. 

During bootup, after setting the SCAN_ALL_LUNS in the kernel config and
rebuilding it, the changer robot in the tape drive is found, at the same
address, 0,0,6 as the drive itself, but the drive is LUN=0 where the
changer is LUN=1.

If i address the drive at /dev/tape which is a link to /dev/nst0, then
where does the changer show up for mtx, and/or amanda's amtape utility?

I seem to be getting errors from /dev/sg for some of the sample command
lines I've tried, and the last I heard, sg was my cd burner here at home.

Cheers, Gene
-- 
  Gene Heskett, CET, UHK       |Amiga A2k Zeus040, Linux @ 500mhz 
        email gene underscore heskett at iolinc dot net
#Amiga based X10 home automation program EZHome, see at:#
 <http://www.iolinc.net/gene_heskett>
This messages reply content, but not any previously quoted material,
is � 2001 by Gene Heskett, all rights reserved.  Due to recent
changes in M$ lusers TOS, mail from msn.com, msn.net, microsoft.com,
microsoft.net, hotmail.com, and hotmail.net is auto-deleted, unread.
-- 


------------------------------

From: Katie Mueller <[EMAIL PROTECTED]>
Subject: /ttyS0
Date: Sat, 26 May 2001 00:40:31 -0400

I have hooked up to computers through a db9 via a null modem cable. I have
written a talk program that has the following protocol. 
1. A terminal start off as a  sender or reciever.
2. If sender then the user will input to stdin.
   The data from stdin will be buffered 
   The buffered data will be transmitted via ttyS0
   ttyS0 will initially be opened for output then immediately closed
   after output takes place. This side will end up now waiting for data
   or response via ttyS0 being opened for read.

3. If terminal starts off as reciever then it does the exact opposite of
the sender.


Problem:
It works for the first transmission but after that it freezes. (i.e 
The one process that was initially sending will not receive, However the
other process is able to send.)

Please help

Katie Mueller

****************************
Katie Mueller
[EMAIL PROTECTED]
****************************


------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Kernel (mal)function after harmless driver Segmenttion Error
Date: Sat, 26 May 2001 09:07:27 +0000

Norm Dresner wrote:
> 
> Kasper Dupont <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Norm Dresner wrote:
> > >
> > > A few weeks ago I'd noticed that when a new driver I was writing crashed
> > > with a segmentation error that the system log ceased to function.
> Several
> > > readers in this newsgroup pointed out that the failure could have been
> > > caused by my driver clobbering essential kernel code, and I while I
> didn't
> > > agree, I couldn't  prove otherwise.
> > >
> > > Yesterday, after finally getting the driver working, I intentionally
> > > introduced a controllable segmentation fault into it via an ioctl-code
> which
> > > tried to read from the raw PCI address -- not the ioremap-ed virtual
> address
> > > that I know works.  That's all it did: read a word from this address
> into a
> > > local variable and if successful print it out via printk().
> > >
> > > And, exactly as before, after the segmentation fault, the system log was
> > > inoperative.  This time I know that there was no clobbering of kernel
> code.
> > > So ...  I ask again:  Why does the system log either die or hang after
> any
> > > segmentation error?
> > >
> > > Thanks
> > >     Norm
> >
> > A segmentation fault in the kernel can lead to
> > inconsistency in the internal data structures.
> > Even if you don't change anything there might
> > be problems because some of the procedure calls
> > on the stack might have started doing something
> > that they don't get the chacne to finish.
> >
> > Unless you know the exact layout of the kernel
> > stack and how these functions work you will not
> > be able to tell wether the kernel is left in a
> > consistent state.
> >
> > --
> > Kasper Dupont
> 
>     So you're saying that this is an intentional "feature" to prevent
> further corruption of the kernel?
> 
>         Norm

No, I'm just saying that in the case of a bug in
kernel space you will never know what is going
to happen.

If the bug is detected the current process will
be killed, and in some cases the system will
keep runing.

But although the system keeps runing it might
not be as stable as usual. It is up to you to
get the system rebooted. The kernel will just do
what it has to, which might involve killing
processes. Perhaps you somehow killed you syslog
process or the process being killed were holding
some locks preventing the syslog process from
runing. Certainly nobody will try to prevent you
from loging in the case of a kernel bug, it is
one of the most important services to try to
keep runing as long as posible.

-- 
Kasper Dupont

------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: Win NT boot and Lilo boot
Date: Sat, 26 May 2001 09:25:39 +0000

If the BIOS is able to address both devices at the
same time, I think the only way they can be addressed
is as 0x80 for the boot device and 0x81 for the other
device. I think we should just hope that your BIOS
actually does work this way, it is the most likely
situation.

It is not a problem that you are using NTFS, when I
suggested using a DOS utility to read the cylinders
from the disk I was talking about the layer bellow
the FS. Any DOS utility capable of reading the
cylinders using the INT 0x13 interface will do. I
know that that DISKEDIT from Norton Utilities will
do, if you don't have that I will find a program I
once wrote that can do what you need.

Hugin wrote:
> 
> Hellu,
> 
> I have no idea how the BIOS adress boot-devices. It's an Award 4.51 bios
> on an Abit BX6-2 mainboard. My win2k fs is NTFS, so accessing the
> first few bootsectors are difficult using Dos programs (?).
> 
> I'll test your idea if I don't figure something else out. Personally I
> believe
> it's very simple to solve this, but I've never faced this problem before
> either...
> 
> Thank you for your help!
> 
> "Kasper Dupont" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Hugin wrote:
> > >
> > > Hello,
> > >
> > > I've got a Win2000 install on a 90GB Raid array on a Promise
> > > FastTrak100 controller. To boot of this I have to set my BIOS to
> > > boot SCSI first. I also have a linux install on a 9GB harddisk
> > > connected as secondary master. To boot of this I have to set
> > > the BIOS to boot C first.
> > >
> > > Is there a way (either by using Lilo or NT loader) so that I can
> > > choose which OS to use during boot?
> > >
> > > The problem is that Lilo can't see the raid array, as it is not
> supported
> > > under Linux. Also tried to add a line to boot.ini and created a
> > > bootsect.lnx file on the raid array which points to the linux unstall,
> > > but had no luck so far...
> > >
> > > Suggestions?
> > >
> > > Thanks!
> >
> > Do you know how the BIOS assigns driver numbers to
> > the drives in the two cases?
> >
> > Usually the boot device is assigned number 0x80,
> > and I would expect the other drive to be assigned
> > 0x81. Do you know if your BIOS actually does this.
> >
> > I don't know the NT loader, so I cannot help you
> > with that, but I have an idea to how it might be
> > posible to get it working using LILO.
> >
> > In some way copy the first few (logical) cylinders
> > of the SCSI drive to a file. If you cannot do this
> > from within w2k try some dos utility.
> >
> > Copy this file to your Linux partition, if you
> > cannot do this directly you might get it working
> > by copying it to a floppy first.
> >
> > Now tell LILO that this file is actually BIOS
> > device number 0x81, I don't know if LILO will
> > believe this perhaps it will help to connect it
> > to a loopback device using the losetup command.
> >
> > Maybee in this way it will be possible for LILO
> > to install a map that will actually be able to
> > boot your w2k disk.
> >
> > I don't know how much of your SCSI disk will be
> > needed in the file. Perhaps 512 bytes is enough,
> > perhaps you need 32KB or maybee a lot more. This
> > is just an idea, I've never tried anything like
> > this.
> >
> > --
> > Kasper Dupont

-- 
Kasper Dupont

------------------------------

From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: ext2 limitations
Date: Sat, 26 May 2001 13:49:00 +0100

In article <obEP6.2467$[EMAIL PROTECTED]>, "Jason Kusar"
<[EMAIL PROTECTED]> wrote:


> What am I looking at, the inode count??  what tells me the max entries??
> 

Yep,  you can also verify it when mounted by doing a df -i

karl.

------------------------------

From: "Norm Dresner" <[EMAIL PROTECTED]>
Subject: Re: Kernel (mal)function after harmless driver Segmenttion Error
Date: Sat, 26 May 2001 16:28:13 GMT

Kasper Dupont <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Norm Dresner wrote:
> >
> > Kasper Dupont <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Norm Dresner wrote:
> > > >
> > > > A few weeks ago I'd noticed that when a new driver I was writing
crashed
> > > > with a segmentation error that the system log ceased to function.
> > Several
> > > > readers in this newsgroup pointed out that the failure could have
been
> > > > caused by my driver clobbering essential kernel code, and I while I
> > didn't
> > > > agree, I couldn't  prove otherwise.
> > > >
> > > > Yesterday, after finally getting the driver working, I intentionally
> > > > introduced a controllable segmentation fault into it via an
ioctl-code
> > which
> > > > tried to read from the raw PCI address -- not the ioremap-ed virtual
> > address
> > > > that I know works.  That's all it did: read a word from this address
> > into a
> > > > local variable and if successful print it out via printk().
> > > >
> > > > And, exactly as before, after the segmentation fault, the system log
was
> > > > inoperative.  This time I know that there was no clobbering of
kernel
> > code.
> > > > So ...  I ask again:  Why does the system log either die or hang
after
> > any
> > > > segmentation error?
> > > >
> > > > Thanks
> > > >     Norm
> > >
> > > A segmentation fault in the kernel can lead to
> > > inconsistency in the internal data structures.
> > > Even if you don't change anything there might
> > > be problems because some of the procedure calls
> > > on the stack might have started doing something
> > > that they don't get the chacne to finish.
> > >
> > > Unless you know the exact layout of the kernel
> > > stack and how these functions work you will not
> > > be able to tell wether the kernel is left in a
> > > consistent state.
> > >
> > > --
> > > Kasper Dupont
> >
> >     So you're saying that this is an intentional "feature" to prevent
> > further corruption of the kernel?
> >
> >         Norm
>
> No, I'm just saying that in the case of a bug in
> kernel space you will never know what is going
> to happen.
>
> If the bug is detected the current process will
> be killed, and in some cases the system will
> keep runing.
>
> But although the system keeps runing it might
> not be as stable as usual. It is up to you to
> get the system rebooted. The kernel will just do
> what it has to, which might involve killing
> processes. Perhaps you somehow killed you syslog
> process or the process being killed were holding
> some locks preventing the syslog process from
> runing. Certainly nobody will try to prevent you
> from loging in the case of a kernel bug, it is
> one of the most important services to try to
> keep runing as long as posible.
>
> --
> Kasper Dupont

In the instance in question, I didn't corrupt anything; that's guaranteed:
all I did was to add a single additional memory reference to read from an
address that I knew would produce a segmentation error; since the data was
read into a temporary variable, there's absolutely no chance of corrupting
the kernel in any way.

BUT ...
    IIRC, the driver had the code:

        int        temp;
              ..
        printk( KERN_ERR "Value is %d\n" , temp = ReadFromNowhere() );

where the ReadFromNowhere function contains the intentional error.

    Is it possible that there's an implicit lock on the kernel-log pending
the completion of the memory access that was never released because the
process was killed by the seg-fault?

    Norm




------------------------------

From: "psy" <[EMAIL PROTECTED]>
Subject: Help!!
Date: Sat, 26 May 2001 12:35:09 -0400

As a Linux newbee, I installed RedHat 7.1 successfully even though I am
having some darn problems (which is normal when you don't master a new
OS!!).

Here there are.

1- When booting, it is said that "Bringing up interface etho" is
unsuccessful.  What does this mean and what should I do??

2- I have a cable modem.  However, on KDE, I was not able to find where I
could setup my internet!!  It talked about internet ISDN, regular modem
(dial up), etc. but nothing on cable modem.  Consequently, I cannot use
internet...

3- When I put a cd on my cd-rom hardware, it works fine but I cannot re-open
the door anymore!!  I pressed the exit button many times, without any
success...  What did I do wrong?

Finally, is it normal that when I want to open an application, it takes
around 7 seconds to open it?  It seems to be quite slow...  (example, when I
pressed mouse config, a blank screen appears for 7 seconds before I get any
opportunity to make a change...)

Zillion of thanks to all of you!!

>From a proud new Linux learner...



--
Daniel
Visitez mon site Web!!
http://dromadaire.com/cimetiere/psychologie



------------------------------

From: Mike Hebert <""hurricane3\"@nospam.home.com (remove \"nospam\")>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: C++ linux server to java client: connection problem
Date: Sat, 26 May 2001 16:43:19 GMT

Somkith Chai wrote:

> Hello,
> 
> I'm running into problems sending data between my server and client.  My
> server is compiled using Linux C++ and my client is on java.  I'm getting a
> Connection refused on the java side.  I've also seen situations with the
> error Connection reset by peer.  Similar server code compiled on Solaris
> works fine.  It looks like the close() is terminating the connection
> prematurely on Linux.  If I put a sleep just before the close() statement,
> the data is sent.  Can anyone tell me what is going on?  I've copied my
> code below.



>  ret = write(sd_out, buf, 50000);
>  printf("write returned %d...\n", ret);


I wonder: does it work if you use a "send" here rather than a "write"?

Another thing to try is a fflush(sd_out) just before you close the 
connection.

Let me know if these work!


------------------------------

From: VRETOS Nicholas <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: C++ linux server to java client: connection problem
Date: Sat, 26 May 2001 20:43:13 +0200

Somkith Chai wrote:

> Hello,
>
> I'm running into problems sending data between my server and client.  My
> server is compiled using Linux C++ and my client is on java.  I'm getting a
> Connection refused on the java side.  I've also seen situations with the
> error Connection reset by peer.  Similar server code compiled on Solaris
> works fine.  It looks like the close() is terminating the connection
> prematurely on Linux.  If I put a sleep just before the close() statement,
> the data is sent.  Can anyone tell me what is going on?  I've copied my
> code below.
>
> My Linux is Red Hat 6.2 and I am using jdk1.3.0_02.
>
> Any help would be appreciated.
>
> Thanks,
> Somkith Chai
>
> Server Code (C++):
>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <stdlib.h>
> #include <stdio.h>
> #include <netinet/in.h>
> #include <netdb.h>
> #include <string.h>
> #include <unistd.h>
>
> int main(int argc, char *argv[])
> {
>  int ret, sd, sd_out;
>  struct linger l;
>  l.l_onoff = 1;
>  l.l_linger = 100;
>
>  printf("Starting program!\n");
>
>         sd = socket (PF_INET, SOCK_STREAM, IPPROTO_TCP);
>         printf("Creating socket descriptor: %d\n", sd);
>
>  struct sockaddr_in addr;
>  memset ((char*)&addr, 0, sizeof (struct sockaddr_in));
>  addr.sin_family = AF_INET;
>  addr.sin_addr.s_addr = INADDR_ANY;
>  addr.sin_port = 56325;
>
>  ret = bind(sd, (struct sockaddr *)&addr, sizeof (struct sockaddr_in));
>  printf("bind returned %d...\n", ret);
>
>   ret = listen (sd, 10);
>   printf("listen returned %d...\n", ret);
>
>  struct sockaddr_in addr_out;
>  sd_out = accept(sd, (struct sockaddr *)&addr_out, (socklen_t *) sizeof
> (struct sockaddr));
>
>  ret = setsockopt(sd_out, SOL_SOCKET, SO_LINGER, (char *) &l, sizeof(l));
>  printf("setsockopt returned %d...\n", ret);
>
>  char buf[50001];
>  memset(&buf[0], (int)'1', 50000);
>
>  ret = write(sd_out, buf, 50000);
>  printf("write returned %d...\n", ret);
>
>  close(sd_out);
>  close(sd);
>
>  printf("Ending program!\n");
>  return 0;
> }
>
> Client Code (java):
>
> import java.util.*;
> import java.io.*;
> import java.net.*;
>
> class myClient
> {
>  public static void main( String[] args )
>  {
>   try
>   {
>    String hostname = "puppy";
>    int hostport = 1500;
>
>    URL url = new URL("http", hostname, hostport, "service");
>    HttpURLConnection c = (HttpURLConnection)url.openConnection();
>    c.setRequestMethod("POST");
>    c.setDoOutput(true);
>    c.connect();
>
>    OutputStream os = c.getOutputStream();
>
>    PrintStream ps = new PrintStream(os);
>    ps.println(" ");
>    os.close();
>
>    InputStream is = c.getInputStream();
>    BufferedReader dis = new BufferedReader(new InputStreamReader(is));
>    String buffer = "";
>    int contentLength = 50000;
>
>    System.out.println("contentLength = " + contentLength);
>
>    char[] buf = new char[contentLength + 1];
>    int resul = dis.read(buf,0,contentLength);
>    buf[contentLength] = '\0';
>
>    System.out.println("resul = " + resul);
>    System.out.println("buffer content...");
>    System.out.println(buf);
>
>    dis.close();
>    is.close();
>    c.disconnect();
>   }
>   catch (Exception e)
>   {
>    System.out.println(e.getMessage());
>   }
>  }
> }

Hi Somkith,
    I think that your lisent() function in the server side programme dosn't
function prety well. Trie to make some tests over it (things  like " if (
(ret=lisent(.....))<0) { perror ....."))
    it imaybey helpfull for you to understand what is going on if this is a
lisent() function problem
    Somthing else is that your setsockoption() function set options for
sd_out. Normally you have to do that befor bind() your socket  on the  sd
socket descriptor ("setsockopt(/*sd_out*/ sd, SOL_SOCKET, SO_LINGER, (char *)
&l, sizeof(l));" befor bind() function )
  last think try to use the recv() function than a simple write() it's more
powerfull and flexiball in this case (socket programming).

    I hope this will help you.

    Bye Nicholas



------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list by posting to the
comp.os.linux.development.system newsgroup.

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to