Re: Text file busy
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
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
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
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: Synaptics touchpad support
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: if_sis.c 1.61 breaks support for SiS630 chipset (fwd)
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: finger -l [EMAIL PROTECTED]
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 Integrated Systems (SiS)'
device = 'SiS900 Fast Ethernet/Home Networking Ctrlr'
class= network
subclass = ethernet
ohci0@pci0:1:2: class=0x0c0310 card=0x70011039 chip=0x70011039 rev=0x07
hdr=0x00
vendor = 'Silicon Integrated Systems (SiS)'
device = 'SiS5597/8 Universal Serial Bus Controller'
class= serial bus
subclass = USB
ohci1@pci0:1:3: class=0x0c0310 card=0x70001039 chip=0x70011039 rev=0x07
hdr=0x00
vendor = 'Silicon Integrated Systems (SiS)'
device = 'SiS5597/8 Universal Serial Bus Controller'
class= serial bus
subclass = USB
pcm0@pci0:1:4: class=0x040100 card=0x040114ff chip=0x70181039 rev=0x02
hdr=0x00
vendor = 'Silicon Integrated Systems (SiS)'
device = 'SiS7018 PCI Audio Accelerator'
class= multimedia
subclass = audio
none0@pci0:1:6: class=0x070300 card=0x100514ff chip=0x70131039 rev=0xa0
hdr=0x00
vendor = 'Silicon Integrated Systems (SiS
if_sis.c 1.61 breaks support for SiS630 chipset
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
http://www.freebsd.org/cgi/getmsg.cgi?fetch=1164115+1166406+/usr/local/www/db/text/2003/freebsd-current/20030112.freebsd-current
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
See http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/46628. $.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
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?
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
