Re: Text file busy

[Mikko Työläjärvi]

On Thu, 4 Sep 2003, Scott M. Likens wrote:

> On Thu, 2003-09-04 at 07:44, Paul Richards wrote:
> > Overwriting a file that's currently executing results in a "Text file
> > busy" error.
> >
> > When did this start happening?
> >
> > This was something that was fixed way back on FreeBSD but it seems to be
> > a problem again.
> >
> > Paul.
>
> this "feature" has always existed in FreeBSD for as long as I remember.
>
> Of course there are ways to bypass this "feature" but it's there for
> your protection.  You shouldn't be upgrading a program that's in
> resident memory.  That's like trying to reinstall X while running in X.
> You're just asking for problems.
>
> turnoff postfix, install the new version and be happy.
>
> Every single 'flavor' of Unix/Unices has always had this feature.  I've
> seen it on HP-UX box's on Solaris Servers, Linux, NetBSD, OpenBSD,
> FreeBSD.  Maybe you wern't paying attention but, that is one of those
> things I think should fall under duh, i shouldn't do that it might make
> things crash hard.

SunOS 4 let you overwrite binaries for running programs, which almost
surely made them crash.  HP-UX has the annoying misfeature that you
cannot even unlink a binary used for paging.

The way to do it is to mv/rm te target before installing the new
version.  AFAIK install(1) will do the right thing.

If you are into foot shooting, you can always overwrite a shared lib,
such as libc.so, and watch (almost) all your programs crash and burn :-)

   $.02,
   /Mikko
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Problem with USB ulpt0 and CUPS

[Mikko Työläjärvi]

On Wed, 18 Jun 2003, Thomas T. Veldhouse wrote:

> I posted this in April and received no response.  However, this has been an
> ongoing issue since at least 2001 (where I found the first reference to this
> trouble via Google).
>
> The problem seems to be that the FreeBSD USB LPT driver (even with no-reset)
> is somehow dropping the first bits of the data stream, causing a page full
> of trash to be printed prior to the actual print job.  I have no verified
> this problem with 5.1-RELEASE as well.

FWIW, I had similar problems with USB printer and 4.7.  Inserting a
sleep(1) between opening the device and the first write proved to be
a sufficient workaround.

   $.02,
   /Mikko
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: -CURRENT + cvs = panic

[Mikko Työläjärvi]

On Tue, 4 Mar 2003, Vladimir Kushnir wrote:

> On Mon, 3 Mar 2003, Philipp Mergenthaler wrote:
>
> > On Mon, Mar 03, 2003 at 01:23:20AM +0200, Vladimir Kushnir wrote:
> > > Practically 100% repeatable: after some CVS updates (not sure but it
> > > seems after another high HD load as well) -CURRENT panics with
> > > bwrite: buffer is not busy
> > > (in the prefious message I've attached gdb trace and so on, and nothing
> > > has changed so far).
> > > It goes on for at least several days now.
> >
> > In that gdb trace, I think the panic was only an aftereffect and
> > the trouble started here:
> > #15 0xc02bc1c8 in calltrap () at {standard input}:96
> > #16 0xc021fd79 in tcp_input (m=0xc0d49c30, off0=20)
> > at /usr/src/sys/netinet/tcp_input.c:2324
> >
> > Do you have version 1.198 of sys/netinet/tcp_input.c?  I haven't had
> > that panic since then (i.e. for the last four days).
> >
> > Bye, Philipp
> >
> Yes:
> src/sys/netinet/tcp_input.c,v 1.198 2003/02/26 18:20:41
> Doesn't help, though. Of all "cvs up ..." or "cvsup ..." there was 1 or 2
> that did not panic :-(

Just to chime in: I get these panics almost daily on my laptop since
the last update (including tcp_input.c 1.198).  They used to happen
before as well, but less frequently.  Sadly, I no longer seem to get
crashdumps, but back when I did get them, the code path looked the
same (trap somewhere in tcp_input).

The crashes can happen at any time, even under very light load and are
invariably preceeded by the mouse freezing up, then a flurry of
error messages like:

  psmintr: delay too long; resetting byte count
  psmintr: out of sync ( != 0080).
  psmintr: discard a byte (1).
  psmintr: delay too long; resetting byte count
  psmintr: out of sync ( != 0080).
  psmintr: discard a byte (1).

Then the mouse recovers, but after that it looks like almost any
network activity will trigger a panic.  WITNESS does not print
anything.

  $.02,
  /Mikko

(Since the d*mn ACPI does not work anyway, I predict a "downgrade" to
 4.8 in the near future...)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Synaptics touchpad support

[Mikko Työläjärvi]

On Mon, 10 Feb 2003, Paul A. Mayer wrote:

> Well, it compiles on 5.0-Release-p1.  The psm initialization gives some
> specs about the device and some of it's features. ... but I don't see
> any consequences of this in apps, like mozilla.  And under gnome the
> pressure sensitivity of the touchpad (e.g., tap to click) is now gone.
>
> I have no great understanding of how any of this should work.  Can you
> give some pointers.  (How do I get touch sensitivity back?  How should
> it be configured into X?  Where should I be able to see the effects of
> the patch?)

Here is what I'm using.  In /etc/rc.conf:

  moused_enable="YES"
  moused_flags="-m2=4 -m4=2"

And in /etc/X11/XF86Config:

  Section "InputDevice"
Identifier  "Mouse0"
Driver  "mouse"
Option  "Protocol" "Auto"
Option  "Device" "/dev/sysmouse"
Option  "Resolution" "250"
Option  "EmulateWheel"
Option  "EmulateWheelInertia" "60"
Option  "EmulateWheelButton" "4"
Option  "Buttons" "4"
  EndSection

This gives me 3 buttons, plus an emulated "scroll wheel", when I hold
down the fourth button and move my finger up or down on the mousepad.
(see mouse(4) in /usr/X11R6/man, not mouse(4) in /usr/share/man...)

$.02,
/Mikko


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Synaptics touchpad support

[Mikko Työläjärvi]

On Mon, 10 Feb 2003, Terry Lambert wrote:

[...]

> You actually lose the tap/tap-tap click and doubleclick button
> emulation with the new driver, and, as you note, the pressure
> sensitivity.

[...]

> Probably the best thing to do would be to disassemble the BIOS on
> your box, knowing the difference between the older driver's interface,
> and use the same techniques that were hidden from the older driver
> (and "just built in" instead).

I doubt that would help.

The mousepad can operate in two different modes, in the basic mode you
get built-in tapping, but only two buttons, in the other mode you get
more information (e.g. all buttons), but have to figure out the tap
action yourself from the pressure delta over time.

The behavior is documented by the manufacturer (synaptics.com.tw), who
actually provides specs on-line (whee!).

  $.02,
  /Mikko
  (who likes using all buttons and have learned to live without tapping...)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: if_sis.c 1.61 breaks support for SiS630 chipset (fwd)

[Mikko Työläjärvi]

Hmm... my MUA dropped Cc: current somewhere along the line.

   /Mikko

On Mon, 20 Jan 2003, Martin Blapp wrote:

>
> Hi,
>
> And you just added this part ? Maybe we can then just check the
> revision and do the old read part for rev > rev 0x90. You should
> not use then the bitbang method then. If I get it right you do both
> in your patch, the first fails silently, the second works. Right ?
>
> Martin

I believe the chip does support the bitbang method, but for some
reason fails to work as the code expects in at least one place.

Not being overly familiar with neither the chip nor MII, I simply
added the smallest amount of code from the last working revision
in order to get my laptop back on line.

It is a workaround, not a solution.

   Regards,
   /Mikko

>
> Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
> --
> ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH
> Phone: +41 61 826 93 00 Fax: +41 61 826 93 01
> PGP: 
> PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E
> ------
>
> On Mon, 20 Jan 2003, Mikko Työläjärvi wrote:
>
> >
> > Hello,
> >
> > On Mon, 20 Jan 2003, Martin Blapp wrote:
> >
> > >
> > > hi,
> > >
> > > > Can you post me a "pciconf -lv" I need the revision number of your
> > > > integrated nic.
> >
> > Full pciconf output included for your reading pleasure :-)
> >
> > > Sorry, over read it.
> > >
> > > Can you post me the whole patch which you've made to get it
> > > working again ?
> >
> > Sure.  Seems like it is just the read code that does not work with my
> > chipset.  This is simply the chunk of code that was replaced in rev
> > 1.61, but wrapped inside an if-statement.  Dunno if the condition is
> > correct: I only have one sis-equipped computer to test with.
> >
> >  Regards,
> >  /Mikko
> >
> > --- if_sis.c.1.62   Sun Jan 19 14:35:57 2003
> > +++ if_sis.cSun Jan 19 15:14:54 2003
> > @@ -735,6 +735,39 @@
> > sc->sis_rev < SIS_REV_635 && phy != 0)
> > return(0);
> >
> > +#if 1
> > +   /*
> > +* Hack: The new code below does not work with my sis630S.
> > +*   Revive wokring code from r1.60
> > +*/
> > +
> > +   if (sc->sis_type == SIS_TYPE_900 && sc->sis_rev <= SIS_REV_630S) {
> > +   int i, val = 0;
> > +
> > +   CSR_WRITE_4(sc, SIS_PHYCTL,
> > +   (phy << 11) | (reg << 6) | SIS_PHYOP_READ);
> > +   SIS_SETBIT(sc, SIS_PHYCTL, SIS_PHYCTL_ACCESS);
> > +
> > +   for (i = 0; i < SIS_TIMEOUT; i++) {
> > +   if (!(CSR_READ_4(sc, SIS_PHYCTL) & SIS_PHYCTL_ACCESS))
> > +   break;
> > +   }
> > +
> > +   if (i == SIS_TIMEOUT) {
> > +   printf("sis%d: PHY failed to come ready\n",
> > +  sc->sis_unit);
> > +   return(0);
> > +   }
> > +
> > +   val = (CSR_READ_4(sc, SIS_PHYCTL) >> 16) & 0x;
> > +
> > +   if (val == 0x)
> > +   return(0);
> > +
> > +   return(val);
> > +   }
> > +#endif
> > +
> > bzero((char *)&frame, sizeof(frame));
> >
> > frame.mii_phyaddr = phy;
> >
> > sotec% pciconf -lv
> > hostb0@pci0:0:0:class=0x06 card=0x chip=0x06301039 rev=0x31 
>hdr=0x00
> > vendor   = 'Silicon Integrated Systems (SiS)'
> > device   = 'SiS630 Host-to-PCI Bridge'
> > class= bridge
> > subclass = HOST-PCI
> > atapci0@pci0:0:1:   class=0x010180 card=0x120114ff chip=0x55131039 rev=0xd0 
>hdr=0x00
> > vendor   = 'Silicon Integrated Systems (SiS)'
> > device   = 'SiS5513 EIDE Controller (A,B step)'
> > class= mass storage
> > subclass = ATA
> > isab0@pci0:1:0: class=0x060100 card=0x chip=0x00081039 rev=0x00 
>hdr=0x00
> > vendor   = 'Silicon Integrated Systems (SiS)'
> > device   = 'SiS85C503/5513 PCI to ISA Bridge (LPC Bridge)'
> > class= bridge
> > subclass = PCI-ISA
> > sis0@pci0:1:1:  class=0x02 card=0x020114ff chip=0x09001039 rev=0x82 
>hdr=0x00
> > vendor   = 'Silicon I

if_sis.c 1.61 breaks support for SiS630 chipset

[Mikko Työläjärvi]

Hello,

Version 1.61 of if_sis.c breaks support for SiS630, or at least the
one on my laptop. This has been noted before, in

I just though I'd add some more details.

The device probe fails with:

  sis0: MII without any PHY!

pciconf reports the chip as:

 sis0@pci0:1:1:  class=0x02 card=0x020114ff chip=0x09001039 rev=0x82 hdr=0x00
vendor   = 'Silicon Integrated Systems (SiS)'
device   = 'SiS900 Fast Ethernet/Home Networking Ctrlr'
class= network
subclass = ethernet

Things start to go bad when sis_mii_readreg() ends up in the ack
failure case (around line 622):

/*
 * Now try reading data bits. If the ack failed, we still
 * need to clock through 16 cycles to keep the PHY(s) in sync.
 */
if (ack) {
for(i = 0; i < 16; i++) {
SIO_CLR(SIS_MII_CLK);
DELAY(1);
SIO_SET(SIS_MII_CLK);
DELAY(1);
}
goto fail;
}


Conditionally reverting part of sis_miibus_readreg() to r1.60 is
sufficient to make things work again:

--- if_sis.c.1.62   Sun Jan 19 14:35:57 2003
+++ if_sis.cSun Jan 19 15:14:54 2003
@@ -735,6 +735,39 @@
sc->sis_rev < SIS_REV_635 && phy != 0)
return(0);

+#if 1
+   /*
+* Hack: The new code below does not work with my sis630S.
+*   Revive working code from r1.60
+*/
+
+   if (sc->sis_type == SIS_TYPE_900 && sc->sis_rev <= SIS_REV_630S) {
+   int i, val = 0;
+
+   CSR_WRITE_4(sc, SIS_PHYCTL,
+   (phy << 11) | (reg << 6) | SIS_PHYOP_READ);
+   SIS_SETBIT(sc, SIS_PHYCTL, SIS_PHYCTL_ACCESS);
+
+   for (i = 0; i < SIS_TIMEOUT; i++) {
+   if (!(CSR_READ_4(sc, SIS_PHYCTL) & SIS_PHYCTL_ACCESS))
+   break;
+   }
+
+   if (i == SIS_TIMEOUT) {
+   printf("sis%d: PHY failed to come ready\n",
+  sc->sis_unit);
+   return(0);
+   }
+
+   val = (CSR_READ_4(sc, SIS_PHYCTL) >> 16) & 0x;
+
+   if (val == 0x)
+   return(0);
+
+   return(val);
+   }
+#endif
+
bzero((char *)&frame, sizeof(frame));

frame.mii_phyaddr = phy;


If anyone has theories for a more correct patch, I'll be happy to try
them out.

   $.02,
   /Mikko


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: rshd and/or pan_setenv() broken

[Mikko Työläjärvi]

See .

$.02,
/Mikko

On Thu, 2 Jan 2003, Bruce Evans wrote:

> rshd now gets killed by signal 11 in pam_putenv() when
> pam_setenv("HOME", ...) is called for "rsh localhost ls".
> The registers for pamh->env and i are both 0 in free(pamh->env[i]),
> although this can't happen since pamh->env[0] must have been accessed
> in openpam_findenv() to get to the free().
>
> "rsh localhost" and "rlogin localhost" still work.  A statically
> linked rshd from last June still works.
>
> Bruce
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: df -l broken

[Mikko Työläjärvi]

On Fri, 30 Nov 2001, Maxime Henrion wrote:

> Mikko Tyolajarvi wrote:
[...]
> > They don't have to be mounted, just loaded.  E.g. if "nfs"
> > shows up with "lsvfs", "df -l " will work, if not, it won't.
> > (dunno about other network file systems).
> [...]
>
> I looked at the code a bit more closely and you're entirely right.  I
> think I figured out why my patch caused a core dump.  Here is a more
> correct patch that should fix the problem without causing core dumps.
>

FWIW: Seems to solve the problem on -STABLE.  Didn't try your earlier
attempt, so I don't have any core dump experiences ;-)

   $.02,
   /Mikko

 Mikko Työläjä[EMAIL PROTECTED]
 RSA Security


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

USB NIC speed?

[Mikko Työläjärvi]

Seeing that -current now supports USB network devices, I got a Linksys
100TX "dongle".  Question is: what kind of speed is reasonable to
expect with this thing?

Some unsophisticated tests show that I get around 3.7 Mbit/sec under
FreeBSD, and about 5.5 Mbit/sec under Windogs98.  This is on a Toshiba
Portegé 3110CT (has a UHCI controller).  The "fxp" device that comes
with the machine can transfer over 8Mbit/sec over the same network (a
fairly idle 10 Mbit segment).

Is this as good as USB networking gets?  Ok, I know that USB won't
handle more than 12 Mbit, but right now it does not even reach one
half that).

At least the USB adapter is more comfortable for laptop use than the
big ugly "docking station" thingie containing the fxp NIC :-)

   Just curious,
   /Mikko

 Mikko Työläjä[EMAIL PROTECTED]
 RSA Security



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message