32/64bit KSE issues?

[David E. Cross]

I recently ran into a problem where the 32bit JVM won't run on a 64bit 
host.  I, and at least one other person in -java thinks it has to do with 
32 bit KSE on a 64bit kernel (I have a vague memory on this somewheres WAY 
back).  Is this still the issue?  Could someone point me in the general 
direction of the specifics of the problem (if they exist, if not, I may 
try to create a simpler test case then java)?


I tried a few searches, but nothing matching what I remembered came up.

--
David E. Cross
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

ASUS DRW-1608P, doesn't write anything

[David E. Cross]

I have problem with an ASUS DRW-1609P with both 5.3 and 5.4.  It won't
write any media.  Even burncd fails with the following error:

(Yes, I know I have test mode on, I got tired of making coasters)
 burncd -f /dev/acd0 -s max -v -t data file.iso  fixate
 adding type 0x08 file mp3.iso.aa size 72 KB 36 blocks
 next writeable LBA 2136
 addr = 2136 size = 73728 blocks = 36
 writing from file mp3.iso.aa size 72 KB
 written this track 1120 KB (0%) total 1120 KB
 only wrote -1 of 32768 bytes: Device busy

Relevent line from dmesg:

acd0: DVDR ASUS DRW-1608P/1.17 at ata1-master PIO4

atapicam doesn't fix it.  UDMA doesn't fix it.  GENERIC kernel.

Reading works fine.

Suggestions?

-- 
David E. Cross
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

5.2.1-RELEASE, SMP, ACPI, Interrupt loop?

[David E. Cross]

I recently upgraded my old P2B-DS dual processor (p2-450Mhz) machine to
5.2.1 everything seemed to be going well, and in fact I didn't notice it
until recently, but even when the machine is idle it is spending 50% of
its time in an interrupt loop (since I have 2 processors, the second one
is free for me to use, since I had only been doing serial tasks I hadn't
had cause to notice).

If I turn off ACPI I keep both processors and everything else,
additionally the interrupt problems go away.  One further note is on
shutdown, right after ACPI is disabled I get a mangled line of text, one
time in particular it said stray irq 2; no idea if it was really irq 2,
it could have been 12, it seems random characters are dropped under the
IRQ storm.

Has anyone seen this?  Better yet, anyone know what I can do about it?
I'd like to keep ACPI support if possible (for things like actually
shutting the computer off in response to ACLine/UPS failure.)

Cheers,
-- 
David E. Cross
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

(hopefully) easy NFS question

[David E. Cross]

I have an NFS server that recently began to display the following behaviour
(technically the brhaviour is displayed on the clients):
(4.6.2-RELEASE)

mount_nfs -3 -T server:/path /mnt (UDP doesn't exhibit this)
dd bs=64k if=/dev/zero of=/mnt/somefile

I now get about 7 times/second on the client:
NFS server server:/path is not responding, still trying
NFS server server:/path is OK.

NFS server is a Dual P2/400, 512MB ECC cache, exact details can be found
in my microuptime() posts last month (which have been solved with a
new powersupply)  They aren't included here for the sake of brevity, and
I hope they don't matter.

A tcpdump on the client shows seemingly normal request/reponses from the 
server and _lots_ of NFS Null requests from client--server.  I am guessing
this is the client trying to see if the server is back?  This is on the order
of many times a second:

21:31:09.275806 client.0  server.nfs: 1448 null (DF)
21:31:09.275900 server.nfsd  client.1015: . ack 91673 win 30280 nop,nop,timestamp 
15510694 88743 (DF)
21:31:09.275993 client.0  server.nfs: 1448 null (DF)
21:31:09.276008 client.0  server.nfs: 1448 null (DF)
21:31:09.276025 client.0  server.nfs: 1448 null (DF)
21:31:09.276137 server.nfsd  client.1015: . ack 94569 win 27384 nop,nop,timestamp 
15510694 88743 (DF)
21:31:09.276409 server.nfs  client.1710096066: reply ok 164 (DF)
21:31:09.276451 client.0  server.nfs: 1448 null (DF)
21:31:09.276466 client.0  server.nfs: 1448 null (DF)

Ethernet card in question is a 3c950C in the server and a FXP 100B in the
client (client is also 4.6.2).  I tested another machine with a 3c950C and
the same client with no errors.  I would say hardware but this is too 
predictable with no dataloss, and this is seemingly initiated on the client.

Any ideas on where to look?
-- 
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

4.6.2-RELEASE and KRB5

[David E. Cross]

I just cvs-ed to RELENG_4_6_2_RELEASE and tried to do a make buildworld
and I get the errors included below.

It _appears_ to be related to the binutils/ld changes that went in,
but I am unsure how that change affected this, and only this.

errors bellow
 make-roken.c
cc -O -pipe  -I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/include  
-I/usr/src/kerberos5/lib/libroken/../../include  
-I/usr/src/kerberos5/lib/libroken/../../../crypto/heimdal/lib/roken  
-I/usr/obj/usr/src/kerberos5/lib/libroken -Wall 
-I/usr/src/kerberos5/lib/libroken/../../include 
-I/usr/src/kerberos5/lib/libroken/../../include -DHAVE_CONFIG_H -DKRB5_KRB4_COMPAT 
-DKRB4 -DINET6   make-roken.c  -o make-roken
/usr/obj/usr/src/i386/usr/libexec/elf/ld: cannot find -lc
*** Error code 1

Stop in /usr/src/kerberos5/lib/libroken.
*** Error code 1

Stop in /usr/src/kerberos5/lib.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.


-- 
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

Re: microuptime?

[David E. Cross]

  # Power management support (see LINT for more options)
  device  apm0at nexus? flags 0x20 # Advanced Power Management
 
 delete this line and build a new kernel.
 
 i got the same problem here with an amd 750mhz and epox mainboard.
 
 after i build a new kernel, the microuptime message disappeared.

Ok, I _used_ to need those lines, I had a broken statclock or somesuch.
Also, I am a bit perplexed.  Why would the PIIX clock _ever_ go backwards?
And why did my upgrades trigger it?  Is it possible I zotted a CPU?

(regardless I will try it and report back, I am just trying to understand
better what is going wrong)

-- 
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

Re: microuptime?

[David E. Cross]

  # Power management support (see LINT for more options)
  device  apm0at nexus? flags 0x20 # Advanced Power Management
 
 delete this line and build a new kernel.
 
 i got the same problem here with an amd 750mhz and epox mainboard.
 
 after i build a new kernel, the microuptime message disappeared.
No go.

I still have microuptime go backwards by 4 _seconds_.  My next step is to
try a UP kernel build, but I already know that will likely fix it :I 
I really want to know why this came up again, and if it means I fried
something.  Could someone point me at documentation on the PIIX timecounter
method, perhaps if I understood how this clock worked I could understand what
is not working correctly.

-- 
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

microuptime?

[David E. Cross]

I haven't seen microuptime messages in a _very_ long time; over this weekend
I replaced the PowerSupply a couple of fans and the CPU heatsinks in my
computer (none were yet bad, but one of the CPU fans was starting to 
slow down, and I had a problem warm-rebooting the machine:  it had a 90% 
chance of hanging from a warm reboot, even if I hit the reset switch before
the BIOS even passed control to boot/loader).  After these upgrades I 
started receiving lots of microuptime errors (note that the reboot problem
went away).  Has anyone seen them?  Do they know what they are indicative of?
(Is it time to toss this MoBo?)

Below is my kernel config dmesg, dmesg of errors, kernel config.  The brief
version is:  dual Pentium II-400Mhz (ecc Cache), P2B-DS ACPI 1012 BIOS,
512M ECC.  Microuptime errors are usually small (1/1000ths of a second, but
some are VERY large; 4 or 5 seconds),  timecounter is PIIX, method 0.  I
included so many of the microuptime errors because it apparently gets
stuck at certain points for long periods of time.


-- Boot Dmesg --
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.6-RELEASE-p3 #0: Fri Jul 19 00:56:33 EDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GEMINI
Timecounter i8254  frequency 1193182 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (380.87-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x652  Stepping = 2
  
Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR
real memory  = 536858624 (524276K bytes)
avail memory = 518643712 (506488K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 - irq 0
FreeBSD/SMP: Multiprocessor motherboard
 cpu0 (BSP): apic id:  1, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  0, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00170011, at 0xfec0
Preloaded elf kernel kernel at 0xc03de000.
Pentium Pro MTRR support enabled
md0: Malloc disk
Using $PIR table, 7 entries at 0xc00f0d20
apm0: APM BIOS on motherboard
apm: found APM BIOS v1.2, connected at v1.2
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard
IOAPIC #0 intpin 19 - irq 2
IOAPIC #0 intpin 18 - irq 5
IOAPIC #0 intpin 17 - irq 10
IOAPIC #0 intpin 16 - irq 11
pci0: PCI bus on pcib0
pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: NVidia Riva TNT graphics accelerator at 0.0 irq 11
isab0: Intel 82371AB PCI to ISA bridge at device 4.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 ATA33 controller port 0xd800-0xd80f at device 4.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xd400-0xd41f irq 2 at device 
4.2 on pci0
usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub1: Texas Instruments UT-USB41 hub, class 9/0, rev 1.00/1.00, addr 2
uhub1: 7 ports with 7 removable, self powered
ums0: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.03, addr 3, iclass 3/1
ums0: 5 buttons and Z dir.
ugen0: Belkin Components product 0x0103, rev 1.10/2.06, addr 4
ugen1: Belkin Components product 0x0103, rev 1.10/2.06, addr 5
ulpt0: Belkin Components F5U002 Parallel printer adapter, rev 1.00/1.04, addr 6, 
iclass 7/1
ukbd0: Microsoft Natural Keyboard Elite, rev 1.00/1.04, addr 7, iclass 3/1
kbd0 at ukbd0
Timecounter PIIX  frequency 3579545 Hz
chip1: Intel 82371AB Power management controller port 0xe800-0xe80f at device 4.3 on 
pci0
ahc0: Adaptec aic7890/91 Ultra2 SCSI adapter port 0xd000-0xd0ff mem 
0xdf80-0xdf800fff irq 2 at device 6.0 on pci0
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
pcm0: Creative EMU10K1 port 0xb800-0xb81f irq 2 at device 9.0 on pci0
xl0: 3Com 3c980C Fast Etherlink XL port 0xb000-0xb07f mem 0xdf00-0xdf7f irq 
5 at device 10.0 on pci0
xl0: Ethernet address: 00:01:02:71:f6:36
miibus0: MII bus on xl0
xlphy0: 3c905C 10/100 internal PHY on miibus0
xlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
bktr0: BrookTree 878 mem 0xe200-0xe2000fff irq 10 at device 11.0 on pci0
iicbb0: I2C bit-banging driver on bti2c0
iicbus0: Philips I2C bus on iicbb0 master-only
iicbus1: Philips I2C bus on iicbb0 master-only
smbus0: System Management Bus on bti2c0
bktr0: Hauppauge Model 38061 B226
bktr0: Hauppauge WinCast/TV, Philips NTSC tuner, remote control.
pci0: unknown card (vendor=0x109e, dev=0x0878) at 11.1 irq 10
ahc1: Adaptec 2940 Ultra SCSI adapter port 0xa800-0xa8ff mem 0xde80-0xde800fff 
irq 11 at device 12.0 on pci0
aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
orm0: Option ROMs at iomem 
0xc-0xc87ff,0xcc000-0xcc7ff,0xd-0xd57ff,0xd8000-0xd9fff on isa0

boot1

[David E. Cross]

I'd like to create a /boot.config switch that will have boot1 _not_ read from
the console; this is for a secure setup.  Would others be interested in these
patches when I finish them?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

Re: boot1

[David E. Cross]

Well, I can do the commit, I am just looking for interest, and code reviewers
;)

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

debugging question

[David E. Cross]

I received the following from gdb today:

#0  0x0 in ?? ()
#1  0x280a8d22 in svc_getreqset2 () from /usr/lib/libc.so.4
#2  0x280a8c5b in svc_getreqset () from /usr/lib/libc.so.4
#3  0x804c85f in yp_svc_run ()
#4  0x804cd94 in main ()
#5  0x8049a09 in _start ()

Uhm... I didn't think that was possible.  I thought the kernel stored the
last stack frame iteslf, from the SIG handler in kernel-space.

-- 
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

ypserv.new (feeback requested)

[David E. Cross]

I notice that a lot of people downloaded the ypserv update.  I also know that
many people have had the same troubles I reported with the 'old' ypserv.
Have any of you who have had troubles tested this version?  Did it work?
For those who are running it, have you noticed any problems?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

ypserv (fixed... I think)

[David E. Cross]

To those of us experiencing problems with ypserv, I have made a copy of
my binary available at:

DO NOT READ ANY FURTHER IF YOU HAVE NOT SETUP AND ADMINED A NIS DOMAIN!
THIS IS NOT FOR YOU!

http://www.cs.rpi.edu/~crossd/FreeBSD/ypserv
MD5 (ypserv) = 1f1c6c01eafd690059b32e615e5b6efc

It is binary only at this point primarily due to license issues (I borrowed
heavily from BDB in my rewrite, and I have not credited things yet.

This code represents the following changes:

1) Fix of a bug in librpc.
2) Fix of some race-conditions in ypserv
3) rewrite of libdb/hash

I would like people to download it and give it a whirl.  I would recommend
the following actions for people wishing to try the code:

1) get a dump of all of your existing ypmaps, for all domains (if you have
   multiple) via ypcat -k MAPNAME.  you can see all of your maps in
   /var/yp/DOMAIN/map

2) Get the start-time, CPU usage, size, RSS, etc of your current ypserv
   process... save this

3) mv /usr/sbin/ypserv /usr/sbin/ypserv.orig.. cp NEWYPSERV /usr/sbin...
   killall ypserv, /usr/sbin/ypserv -FLAGS, rm /ypserv.core, 
   (see previous ypserv information, or consult /etc/rc.conf,
   /etc/defaults/rc.conf)

4) get a ypcat -k MAPNAME again.. compare the output of this to the 
   previous ypserv.  if there are _any_ differences (including order of output
   of the keys, LET ME KNOW.

5) write a script to pull the first word from the previously saved dump-files
   (cut -d   -f 1) -- works for my maps, feed this into
   'ypmatch -k $field MAPNAME anothersavefile' this should also be IDENTICAL
   to the 'ypcat -k' in the previous example.

6) At some future date (after this ypserv has been running about as long as
   the 'original' ypserv, get its information (Size, RSS, CPU, etc) and
   compare them, I am curious.

7) Verify there is no /ypserv.core, ever again.

8) I cannot stress heavily enough, this is for people willing to
   experiment with their systems, if you don't understand NIS, DON'T
   DO THIS!

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

ypserv update

[David E. Cross]

Ok... I have just finished the first step in a rewrite of the hash routines
for berkleydb (read-only at this point), and I have ypserv compiled using
them.  So far so good :).  And ypserv uses a _lot_ less CPU resources now.
(I have totally removed all of the buffer management code in berkley db, and
I am using mmap() exclusively.  Still to be done is to impliment R_CURSOR
type, that will improve ypserv's performance quite a bit in environments
like ours.).  If all goes well (no bugs found), I will put this up on my
website in source-only form tonight.  Maybe be added to ports tonight too.

I am eagerly looking for helpers to complete the hash rewrite, and then
the rest of berkley DB as well.  File format information would be very 
usefull, the stuff that is included with BDB is lacking.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

GRRRR (ypserv)

[David E. Cross]

I am apparently bug-compatible with the original too, though it took
longer to trip over it (and the code runs LOTS faster :)... So probably 
not tonight.  I am going to be placing debugging statements in the code to
see if I can figure out where information is being stepped on.)

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

Re: exec() doesn't update access time

[David E. Cross]

In my case it would be usefull as I was trying to tell the last time
'telnetd' was run. (yes, not perfect, but better than nothing)

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

Re: exec() doesn't update access time

[David E. Cross]

Hmm... would it be as easy as
VOP_GETATTR();
.
.
.
VOP_SETATTR();

within the exec() code?

Certainly this would be an 'easy' fix (and I can work up diffs for review),
but is it the 'correct' fix?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

exec() doesn't update access time

[David E. Cross]

I noticed that exec(2) does not update the last access time of a file...
is this intentional?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

Re: exec() doesn't update access time

[David E. Cross]

Well over NFS an exec will update atime (because NFS doesn't differentiate
between 'exec' and 'read').

Under Solaris8/Sparc (on a memfs mount) exec-ing an executable does indeed
update the access time.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

sound on IBM model T22 laptop

[David E. Cross]

Hello, sound is not working correctly on this IBM model T22 laptop.  
Specifically whenever sound plays it is very garbled.  I can get it
to play almost correctly via either 'ping -f somehost' or
'dd bs=512 if=/dev/zero of=foo.zero'  (well, at least until the filesystem
fills up ;)  the ethernet card is on IRQ 11 (same as the sound chip), but
the IDE controller is on the standard IDE IRQ channel... so I am not quite
sure if this is an IRQ issue.  This is a -STABLE kernel from today.

--kernel config---
machine i386
cpu I686_CPU
ident   TTT
maxusers64

options INET#InterNETworking
options INET6   #IPv6 communications protocols
options FFS #Berkeley Fast Filesystem
options FFS_ROOT#FFS usable as root device [keep this!]
options SOFTUPDATES #Enable FFS soft updates support
options MFS #Memory Filesystem
options MD_ROOT #MD is a potential root device
options NFS #Network Filesystem
options NFS_ROOT#NFS usable as root device, NFS required
options MSDOSFS #MSDOS Filesystem
options CD9660  #ISO 9660 Filesystem
options CD9660_ROOT #CD-ROM usable as root, CD9660 required
options PROCFS  #Process filesystem
options COMPAT_43   #Compatible with BSD 4.3 [KEEP THIS!]
options SCSI_DELAY=15000#Delay (in ms) before probing SCSI
options UCONSOLE#Allow users to grab the console
options USERCONFIG  #boot -c editor
options VISUAL_USERCONFIG   #visual boot -c editor
options KTRACE  #ktrace(1) support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores
options P1003_1B#Posix P1003_1B real-time extensions
options _KPOSIX_PRIORITY_SCHEDULING
options ICMP_BANDLIM#Rate limit bad replies
options KBD_INSTALL_CDEV# install a CDEV entry in /dev

device  isa
device  pci

# Floppy drives
device  fdc0at isa? port IO_FD1 irq 6 drq 2
device  fd0 at fdc0 drive 0
device  fd1 at fdc0 drive 1

# ATA and ATAPI devices
device  ata0at isa? port IO_WD1 irq 14
device  ata1at isa? port IO_WD2 irq 15
device  ata
device  atadisk # ATA disk drives
device  atapicd # ATAPI CDROM drives
options ATA_STATIC_ID   #Static device numbering

# SCSI peripherals
device  scbus   # SCSI bus (required)
device  da  # Direct Access (disks)
device  sa  # Sequential Access (tape etc)
device  cd  # CD
device  pass# Passthrough device (direct SCSI access)

# atkbdc0 controls both the keyboard and the PS/2 mouse
device  atkbdc0 at isa? port IO_KBD
device  atkbd0  at atkbdc? irq 1 flags 0x1
device  psm0at atkbdc? irq 12

device  vga0at isa?

# splash screen/screen saver
pseudo-device   splash

# syscons is the default console driver, resembling an SCO console
device  sc0 at isa? flags 0x100

# Floating point support - do not disable.
device  npx0at nexus? port IO_NPX irq 13

# Power management support (see LINT for more options)
device  apm0at nexus? flags 0x20 # Advanced Power Management

# PCCARD (PCMCIA) support
device  card
device  pcic0   at isa? irq 0 port 0x3e0 iomem 0xd
device  pcic1   at isa? irq 0 port 0x3e2 iomem 0xd4000 disable

# Serial (COM) ports
device  sio0at isa? port IO_COM1 flags 0x10 irq 4
device  sio1at isa? port IO_COM2 irq 3
device  sio2at isa? disable port IO_COM3 irq 5
device  sio3at isa? disable port IO_COM4 irq 9

# Parallel port
device  ppc0at isa? irq 7
device  ppbus   # Parallel port bus (required)
device  lpt # Printer
device  plip# TCP/IP over parallel
device  ppi # Parallel port interface device
#device vpo # Requires scbus and da


device  miibus  # MII bus support
device  fxp # Intel EtherExpress PRO/100B (82557, 82558)

# Pseudo devices - the number indicates how many units to allocate.
pseudo-device   loop# Network loopback
pseudo-device   ether   # Ethernet support
pseudo-device   tun # Packet tunnel.
pseudo-device   pty # Pseudo-ttys (telnet etc)
pseudo-device   md  # Memory 

Re: sound on IBM model T22 laptop

[David E. Cross]

Hmm... an interesting followup to the laste email...


a flood ping FROM the laptop TO another machine clears up the problem... 
a flood ping TO the laptop FROM another machine does nothing.

I assumed this may have had something to do with context switches (or
something)... so I did a 'while (true); do lptest;done'... this also
did nothing, except for the time that the hard-drive read in the text pages,
at this time the sound was clear.

Any ideas what is going on here?  Or what to try next?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

Re: sound on IBM model T22 laptop

[David E. Cross]

Cool

What is the 'long term' fix? (and when will it be in -stable ;)

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

Re: sound on IBM model T22 laptop

[David E. Cross]

It is definitely the powersaving/pci clkrun problem... as that is the only
power change I made ;)

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

ypserv, the continuing battle...

[David E. Cross]

I saw this the other day:

http://www.sleepycat.com/historic.html

Down at the bottom:

 Finally, you should not upgrade your GNU gcc or Solaris compiler.
 Optimizations in versions of gcc 2 that were in alpha test in the
 summer of 1997, and a version of the standard Solaris WorkShop Compiler
 that was in beta test in the fall of 1997, trigger bugs in versions 1.85
 and 1.86 that will cause sporadic core dumps. 

Hmm... does this look familiar to anyone?  What version of berkley DB do
we use 1.85... HMM

My questions are:
1) will gcc without any '-O' flags make a difference?

2) Can we upgrade to the latest Berkley DB (we will need to do a version bump
   of libc to accomplish this.


It is clear that we _must_ do something... the db in our libc is buggy.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

still more ypserv woes

[David E. Cross]

Ok... I am coming to the conclusion that there is some sort of kernel
issue that is causing this problem.  Here is what I have done and discovered
to date (this is all with 4.3-RC2 FWIW):

At some point the 'qhead' CIRCLEQ structure in yp_dblookup.c gets corrupted.
This is declared as a static, and no handles are passed back out of the
function, so aside from data-segment smashing, all accesses to that
structure _must_ happen within yp_dblookup.c.  To date, _almost_ every
single segfault has been in the for loop of yp_testflags (this is a bit
odd in and of itself given that the CIRCLEQ is being mangled) ( I do not
recall the exact situation for the one not in yp_testflags. ), so I 
wrote a function called 'queue_verify()' whose only lob is to travel 
once down the CIRCLEQ, assert the number of entries in the CIRCLEQ is
the same as numdbs and exit.  I placed this function after every
Berkeley DB function call and other random points in the function calls
in "yp_dblookup.c".  Right now I am only seeing seg-faults in the 
queue_verify() that I placed before the for loop in yp_testflags *very*
strange, one would think with the number I have placed everywhere that
it would get tripped up somewhere else too).  I also notice that it
always dies very shortly after it fork()s a child to handle a YP_ALL request
(one of the things the child does is the delete its copy of the CIRCLEQ).
Is it possible that a copy-on-write is somehow getting mangled and causing
this?

FWIW: this system is a single CPU PentiumPro acting as a firewall/gateway with
1 FXP, 2 dc, and 2 xl interfaces (the fxp and one each of the dc and xl are
active).

Any ideas?  Any clue where to look next, I am running out ideas here.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

ypserv: a resolution (i think)

[David E. Cross]

After some more intensive debugging, and a leap of faith, I _think_ I have
the problem licked, but I would appreciate some more brains to examine the
logic. 

The original cause of ypserv's problems was the sharing of DBPs between 
the parent and child.  The resolution to this was to close all of them, in
the child.   This appears to be where the problem lies, it was assumed to
be safe to call the dbclose in the child... apparently dbclose does some
stuff that is still dangerous.  So, my solution is to move the close routine
_before_ the fork (so far *crossed fingers* this is working). However,
since yp_all is called fairly frequently, this is bad(TM) for the parent.
My second solution was to have the child call yp_init_dbs() instead
of yp_flush_all()  (the former would just nuke the references to the FDs, but
actually keep them open).  This didn't work.  Can anyone provide any clues
as to why?  Does the DB library keep its own cache, and unless they are
"really" closed it will just loop back to the open ones anyway?   The
current solution is suboptimal since for many cases it removes the DBCACHE
entirely, but I don't know what other solution exists.

I know some others who use ypserv heavily have run into these problems, if
you need the patch, I can provide it if you are willing to give it a test ;)

JKH:  I think this _really_ needs to get into 4.3-RELEASE, this has been 
a vexing bug for over a year.  The current solution may be sub-optimal, but
it is more optimal than:

pid 75351 (ypserv), uid 0: exited on signal 11 (core dumped)
pid 75364 (ypserv), uid 0: exited on signal 11 (core dumped)
pid 75365 (ypserv), uid 0: exited on signal 11 (core dumped)
pid 75370 (ypserv), uid 0: exited on signal 11 (core dumped)
pid 75377 (ypserv), uid 0: exited on signal 11 (core dumped)
pid 75379 (ypserv), uid 0: exited on signal 11 (core dumped)
pid 75215 (ypserv), uid 0: exited on signal 11 (core dumped)

;)

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

a bug in ypserv found

[David E. Cross]

I have found _a_ bug in ypserv (I think I may be stumbling over multiple
different bugs, but this one is very reproducable).

It is dying in the yp_testflags routine, in the for loop that goes through
the CIRCLEQ.  The loop dies with qptr pointing to a struct that is all NULL
(my reading of CIRCLEQ suggests this isn't supposed to be possible), *and*
qhead (the global variable representing the CIRCLEQ_HEAD) pointing to a
structure that is all NULL (also not supposed to be possible). The fact that
qptr != qhead to me suggests that there was data there when it started, but
that it got ripped out from in under it.  I am not sure how though:
qhead is a "static" global variable, and the only async entry into the 
routine is called from the signal-handler for SIGHUP, problem is that SIGHUP
is not being called.

(Aside: this has been a real pain to track down... I traced it into the
RPC library and back out the other side... NOT FUN)
--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

ypserv (on -RC/-STABLE)... almost there

[David E. Cross]

I have trace the problem in ypserv down to the RPC dispatch routines..
I am digging further and I hope to have it found and eliminated today 
(in time for -RELEASE ;)

If anyone has any idea how it could be tripping up here, please let me
know.  My 2 guesses are a corrupted svc_callback entry (no idea how
it is getting corrupted, yet.) or there is something walking on stuff 
within ypprog_1 or ypprog_2  (I don't know yet if the segfault is
the (sc-dispatch) call in svc.c in the rpc library, or if it is within the
function that sc-dispatch calls  (the next seg-fault will let me know this.)

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

ypserv

[David E. Cross]

Well, I am able to reproduce the crash pretty reliably, I don't know what is
causing it yet, I just kill all the other ypservs on a subnet except for this
one and it crashes about once every 5 minutes.  I have some questions/theories
that I'd like to bounce off of people:

1)  In the yp_all function it calls yp_fork() to fork a new ypserv, the
parent them calls return(NULL); and the child handles the request.
Looking at the ktraces, I notice that the parent does not close
the socket connection, but after the child finishes the transaction
the parent gets a read() return value of 0 (EOF) for that socket and 
then closes it.  Since this is a yp_all request there _shouldn't_ be 
any more read data on the socket until the close event (which is a read
of 0), but that socket is still open in both the parent and the child,
and the child is making calls against it... is there a possibility
of some shared data corruption within the RPC code that anyone could
think of?

2)  The RPC code itself has a lot of checks against blocking... is the forking
of ypserv even needed at all?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

sigh... ypserv bug still very much alive

[David E. Cross]

The ypserv bug (the one where ypserv randomly stops responding or
just seg-faults) is still very much alive.  I had to restart it
about 11 times in the course of 20 minutes this morning.  That's
the bad news, the good news is that I started it each time with
'ktrace -i'.  

Going back a bit, Matt Dillon suggested that the problem may have been
in the signal handler for sigchld.  I looked at the signal handler and 
it does not appear to be doing anything dangerous at all (just a
child_count--;)  is it doing something dangerous that I am just not seeing?

Also, in the last 200 lines of kdump output for each and every crash there
is the sequence of calls select();  gettimeofday();... that sequence of
calls never appears in the ypserv source code, but does appear in svc_tcp.c
in librpc... my question is: ypserv defines its own svc_run, and for
TCP connections specifically handles things itself very carefully, how is
the svc_tcp.c code getting called at all?  I think the answer to that is
the source of the problem (it should also be noted that in the case where
ypserv hasn't died and I have collected ktrace information -- up to 8 gig
of it -- the select(); gettimeofday(); sequence is _never_ called.)

One of my ktrace-s is _very_ small, only 330K, from fork()/exec() to 
SIG_DFL/SEGV, so I am hoping this will provide easily digestible information.
I did not include context-switch information in the ktrace for the following
reasons:
  1) It didn't appear to be usefull, and since I did specify the -i, it is 
 obvious where context switches occur (to the only thing that could affect
 anything: the children)
  2) It caused ypserv to act strangely... instead of dying, it just got
 very slow, and didn't respond.

Anyone interested in helping me track this one down?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

gif(4) question

[David E. Cross]

I recently tried (for the first time) to get gif running under FreeBSD
4.3-BETA (cvsup-ed yesterday).  I noticed the following:

gifconfig gif0 inet 10.1.1.1 10.1.2.1
ifconfig gif0 192.168.1.1 192.168.1.2 netmask 0xff00

and then I 'ping 192.168.1.1' it will try to route the packet instead of 
reply directly.  I need to 'route add 192.168.1.1 127.0.0.1' to have it
reply to the packet directly.  I don't need to do this for other types
of interfaces... did I mess something up, is this how it is supposed to 
be (doesn't seem to be documented as such).

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD

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

Using multiple Malloc-Disks

[David E. Cross]

I need to use multiple malloc disks for a custom net-boot image I am working
on.  The problem is that whenever I access /dev/md1 from the disk it gives
me a 'device not configured' error.  I originally thought that this was an
error in how a preloaded image interfaced with the system, but I also get
this on a disk-booted machine.

Consider the following test:

 dd bs=512 if=/dev/md0c of=/dev/null
 2 Blocks in
 2 Blocks out
 
 dd bs=512 if=/dev/md1c of=/dev/null
 Device not configured.

Yet, according to the manpage:
 The md driver uses the ``almost-clone'' convention, whereby opening de-
 vice number N creates device instance number N+1.

What is wrong here?   A quick look through the source finds there is no code
in the open() routine to create a new instance; though I am not entirely sure
that is where it would be located.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: Device Driver Question (bus_set_resource)

[David E. Cross]

  Thank you...
  
  After a couple of hours, Jon Chen and I have figured out most of what you 
  just said :P :)
  
  How would one use hints with a kld?
 
 Badly. 8(  You can only really set them with the loader right now.
 
 There are a couple of kernel datastores that need some tweaking; the 
 environment is one of them.

Ok, everything is working well, except for one last thing... 
 
I load the driver the first time, and it loads correctly.  I unload it and
reload it and it attempts to attach twice (with the exact same resource
values).  I unload and reload it and it attempts to load 3 times, unload/reload
... 4 times (you see the pattern).  If I load the second module I am working
on (exact same type as this module), it tries to re-attach the old module
"N" times (depending on the number of previous unload/reloads).

I am obviously building up state somewhere in the kernel... how can I get
rid of this "state"?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Device Driver Question (bus_set_resource)

[David E. Cross]

I am writing a simple, I/O only device driver (no lectures about /dev/io
please ;).  It has not PnP abilities, and I have run into the following
problem with bus_set_resource():  

static int das1400adc_isa_probe(device_t dev)
{
struct das1400adc_softc *sc = device_get_softc(dev);
int unit = device_get_unit(dev);
int pnperror;

sc-dev=dev;
sc-unit=unit;
sc-port0=DAS1400ADC_PORT;
sc-port1=sc-port0+11;
sc-port2=sc-port0+0x406;
sc-irq0=0;
sc-port0_rid=0;
sc-port1_rid=0;
sc-port2_rid=0;
sc-low=sc-high=0;

pnperror=ISA_PNP_PROBE(device_get_parent(dev), dev, das1400adc_pnp_ids);
if (pnperror != ENXIO)
return pnperror;

if (bus_set_resource(dev, SYS_RES_IOPORT, /*rid*/sc-port0_rid,
sc-port0, 3)  0)
return ENXIO;
/*  if (bus_set_resource(dev, SYS_RES_IOPORT, sc-port1_rid,
sc-port1, 1)  0)
return ENXIO;
if (bus_set_resource(dev, SYS_RES_IOPORT, sc-port2_rid,
sc-port2, 1)  0)
return ENXIO;
*/
device_set_desc(dev, "CIO-DAS1400-ADC");
return 0; /* all is good */
}

static int das1400adc_isa_attach(device_t dev)
{
struct das1400adc_softc *sc = device_get_softc(dev);

sc-port0_r = bus_alloc_resource(dev, SYS_RES_IOPORT, 
sc-port0_rid, /*start*/0, /*end*/ ~0, /*count*/ 0,
RF_ACTIVE);

/*  sc-port1_r = bus_alloc_resource(dev, SYS_RES_IOPORT,
sc-port1_rid, 0, ~0, 0,
RF_ACTIVE);

sc-port2_r = bus_alloc_resource(dev, SYS_RES_IOPORT,
sc-port2_rid, 0, ~0, 0,
RF_ACTIVE);
*/
if (sc-port0_r == NULL )
/* || sc-port1_r == NULL )
sc-port2_r == NULL)
*/
return ENXIO;

sc-md_dev=make_dev(das1400adc_cdevsw, 0, 0, 0, 0600, "adc0");
sc-open_count=0;
return 0;   
}




Given that code, I get the following attach messages from the kernel:

"das1400adc2: CIO-DAS1400-ADC at port 0x310-0x312 irq 5 drq 1,5 on isa0"
Uhm... I set neither the IRQ nor the drq... where does it get these from, and
how can I get it to "do the right thing"?  Also, If I uncomment the settings
for the additional ranges "really weird things" start to happen.  An example
of 'weirdness' is that exact same code, when kldload-ed will attach a totally
different device. 

Oh yeah, this is under 4.2-STABLE from 20010103.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: Device Driver Question (bus_set_resource)

[David E. Cross]

Thank you...

After a couple of hours, Jon Chen and I have figured out most of what you 
just said :P :)

How would one use hints with a kld?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: Device Driver Question (bus_set_resource)

[David E. Cross]

  Thank you...
  
  After a couple of hours, Jon Chen and I have figured out most of what you 
  just said :P :)
  
  How would one use hints with a kld?
 
 Badly. 8(  You can only really set them with the loader right now.
 
 There are a couple of kernel datastores that need some tweaking; the 
 environment is one of them.

That is what I thought... given my recent performance on "what I thought" WRT
the kernel, I thought I would double check ;)

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: -STABLE+vinum+smp+softupdates+CVSup(local CVS repo)==corruption?

[David E. Cross]

No, I am just using vinum stripes.  The problem seems to have fixed itself
when I got a ufs_readwrite.c update from Matt after it was committed.

This is an interesting problem, since I am not entirely sure what fixed it, 
if it is really fixed, etc...

Sigh, oh well.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

-STABLE+vinum+smp+softupdates+CVSup(local CVS repo)==corruption?

[David E. Cross]

I have run across a problem since updating to -STABLE a week or so ago...
my CVS vinum partition would go corrupt after a few updates.  I have been
running with no softupdates on my system for a day now and no problems.
Has anyone else seen this?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: rpc.lockd and true NFS locks?

[David E. Cross]

I pruned the Cc: list a bit...

One of the email messages that you quoted has the URL for the latest
development of the lockd code.  As far as tests go it appears to be mostly
complete (there appears to be an issue with RPC64 on little endian machines,
but I have not yet had a chance to crawl through the librpc code).  

As for "client" vs. "server", that is quite tricky since WRT NFS locking
they are both client and server.  The "server" side is done and requires no
modifcations to the kernel.  However a FreeBSD kernel is still unable to
acquire an NFS lock.  This latter case is quite likely what your users are
seeing the affects of.

In the end:  the code is there and available for those who want to test and
play with it.  It has not been committed because it is still "broken". 
I could do it to -current or make it a port, if someone were to tell me that
it would be "ok" to do so.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: rpc.lockd and true NFS locks?

[David E. Cross]

Going with the lockd code on builder is great with me.  The last I had
looked it had some of the same issues as the lockd developed here (no
handling of grace periods, etc.), so on a featureset we are even.  The rpics
lockd has the advantage of being known by some of us to a much greater extent
than the BSDI code.  _However_ the BSDI code has undergone much more testing
and design work than the rpics one.  Given this I think the clear choice is
with the BSDI code.

sigh  now, if I wasn't always getting buried with stuff.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: rpc.lockd and true NFS locks?

[David E. Cross]

I'm not going to take such an action w/o the blessing of -core. :)

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

install media problems with latest snapshots

[David E. Cross]

The latest snapshots off of releng4.freebsd.org have a couple of problems
with the kern.flp/mfsroot.flp images.  The first problem is that the
"boot.config" file doesn't exist; this makes serial console installs
problematic (although easily fixed).

Secondly the 2913 image has the problem that the mfsminiroot is wacked
somehow.  The system refuses to mount the md0a partition as the slice size 
and mediasize are not the same (well, it mounts it, tries to run init which
signal 6's, and then the system panic()s).

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

NFS/TCP problems. 4.0-RELEASE server, sol 8 client

[David E. Cross]

I have recently had the time to start devoting more time to FreeBSD;
especially the NFS code.  I have stumbled upon a problem that seems
to be out of my league.

The problem is manifested when NFS/TCP connections just hang.
Sometimes for only a few seconds, other times for minutes.
Below is a network capture of all traffic between a server and a
client (captured from the server):

The intermittent UDP traffic is AMD issuing a null NFS request to
verify that the server is still alive. 

Of note is the very long delays.  Simply put, the FreeBSD box is not
responding, not even an ACK.  Also of note, about line 23 there is
an ACK to a connection that does not even exist, with no noticeable
activity on it for at least 2 seconds; what is is ACK-ing?  It
appears the Sol client keeps issuing RSTs until the client and server
get back in sync WRT TCP sequence numbers, but what is driving them
out of sequence, and why is the FreeBSD server not saying anything
to the client (there is no firewall on any machine in this
configuration.)

22:35:45.342966 10.1.1.1.1020  10.1.1.7.2049: S 1733116406:1733116406(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:35:54.723772 10.1.1.1.1020  10.1.1.7.2049: R 1733116407:1733116407(0) ack 0 win 
24820 (DF)
22:35:54.723870 10.1.1.1.1020  10.1.1.7.2049: S 1747908437:1747908437(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:35:58.094003 10.1.1.1.1020  10.1.1.7.2049: S 1747908437:1747908437(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:36:02.054379 10.1.1.1.7906  10.1.1.7.2049: 40 null (DF)
22:36:02.054668 10.1.1.7.2049  10.1.1.1.7906: reply ok 24 null
22:36:04.844523 10.1.1.1.1020  10.1.1.7.2049: S 1747908437:1747908437(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:36:18.345779 arp who-has 10.1.1.7 (ff:ff:ff:ff:ff:ff) tell 10.1.1.1
22:36:18.345848 arp reply 10.1.1.7 is-at 0:a0:c9:55:94:18
22:36:18.346070 10.1.1.1.1020  10.1.1.7.2049: S 1747908437:1747908437(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:36:32.056867 10.1.1.1.7938  10.1.1.7.2049: 40 null (DF)
22:36:32.057258 10.1.1.7.2049  10.1.1.1.7938: reply ok 24 null
22:36:45.347892 10.1.1.1.1020  10.1.1.7.2049: S 1747908437:1747908437(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:36:54.728709 10.1.1.1.1020  10.1.1.7.2049: R 14792031:14792031(0) ack 1 win 24820 
(DF)
22:36:54.728810 10.1.1.1.1020  10.1.1.7.2049: S 1762707767:1762707767(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:36:58.098954 10.1.1.1.1020  10.1.1.7.2049: S 1762707767:1762707767(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:37:02.059319 10.1.1.1.7970  10.1.1.7.2049: 40 null (DF)
22:37:02.059632 10.1.1.7.2049  10.1.1.1.7970: reply ok 24 null
22:37:04.849475 10.1.1.1.1020  10.1.1.7.2049: S 1762707767:1762707767(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:37:18.350703 arp who-has 10.1.1.7 (ff:ff:ff:ff:ff:ff) tell 10.1.1.1
22:37:18.350788 arp reply 10.1.1.7 is-at 0:a0:c9:55:94:18
22:37:18.350972 10.1.1.1.1020  10.1.1.7.2049: S 1762707767:1762707767(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:37:25.648257 10.1.1.7.2049  10.1.1.1.1022: . ack 73099259 win 33176
22:37:25.648451 10.1.1.1.1022  10.1.1.7.2049: R 73099259:73099259(0) win 0 (DF)
22:37:32.061812 10.1.1.1.8002  10.1.1.7.2049: 40 null (DF)
22:37:32.062179 10.1.1.7.2049  10.1.1.1.8002: reply ok 24 null
22:37:38.483949 arp who-has 10.1.1.254 tell 10.1.1.7
22:37:38.484115 arp reply 10.1.1.254 is-at 0:50:da:23:e7:2
22:37:45.352837 10.1.1.1.1020  10.1.1.7.2049: S 1762707767:1762707767(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:37:54.733653 10.1.1.1.1020  10.1.1.7.2049: R 29591361:29591361(0) ack 1 win 24820 
(DF)
22:37:54.733759 10.1.1.1.1020  10.1.1.7.2049: S 1777476913:1777476913(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:37:58.103890 10.1.1.1.1020  10.1.1.7.2049: S 1777476913:1777476913(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:38:02.064269 10.1.1.1.8034  10.1.1.7.2049: 40 null (DF)
22:38:02.064651 10.1.1.7.2049  10.1.1.1.8034: reply ok 24 null
22:38:04.854408 10.1.1.1.1020  10.1.1.7.2049: S 1777476913:1777476913(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:38:18.355715 10.1.1.1.1020  10.1.1.7.2049: S 1777476913:1777476913(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:38:32.066736 10.1.1.1.8066  10.1.1.7.2049: 40 null (DF)
22:38:32.067015 10.1.1.7.2049  10.1.1.1.8066: reply ok 24 null
22:38:45.357792 10.1.1.1.1020  10.1.1.7.2049: S 1777476913:1777476913(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:38:54.738595 10.1.1.1.1020  10.1.1.7.2049: R 44360507:44360507(0) ack 1 win 24820 
(DF)
22:38:54.738693 10.1.1.1.1020  10.1.1.7.2049: S 1792277515:1792277515(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:38:58.108813 10.1.1.1.1020  10.1.1.7.2049: S 1792277515:1792277515(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:39:02.069178 10.1.1.1.8098  10.1.1.7.2049: 40 null (DF)
22:39:02.069497 10.1.1.7.2049  10.1.1.1.8098: reply ok 24 null
22:39:04.859336 10.1.1.1.1020  10.1.1.7.2049: S 1792277515:1792277515(0) win 24820 
nop,nop,sackOK,mss 1460 (DF)
22:39:18.360595 arp who-has 10.1.1.7 (ff:ff:ff:ff:ff:ff) tell 

4.1-RC + SBLive + ECC = NMI

[David E. Cross]

I upgraded to 4.1-RC1 today; attempted to fire up esound and my system hung.

I rebooted into X, fired up esound from text mode and system hung again
with a message that an NMI was caught.

I remember that the SBLive has some issues with ECC systems, resulting in
some NMIs being thrown.  It would appear that some of the recent fixes in
emu10k1.c v1.6.2.1 tickle this behavior.  I am going to try to back-out to 
1.6 and see if this resolves the issue.  Has anyone else experienced this?
Can I whap creative for producing such great hardware? :)

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: 4.1-RC + SBLive + ECC = NMI

[David E. Cross]

Hmm... backing out to emu10k1.c version 1.6 did not fix my problem.  Does
anyone else have a SBLive! in an ECC machine that is throwing an NMI
whenever you try to use xmms or esd?   If not, I will try to binary search
the dates to see if I can find when the change that tickeled the NMI bug on
the SBLive! was introduced.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

fbsdboot.exe

[David E. Cross]

Yes, I know it is a long dead horse.  

I was just looking for a copy of the modifications that were made by 
Carlos Tapang.  Could someone point me at them, or know Carlos's
current email adress?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: PR #10971, not dead yet.

[David E. Cross]

If you can reproduce the problem regularly then I recommend putting
a signal guard in to see if the corruption is being caused by the
signal interrupting at an inausipcious moment.

In main() block SIGHUP, SIGINT, SIGTERM, and SIGCHLD using sigsetmask().

Just prior to the select call unblock the signals.

Just after the select call reblock the signals.

And see if the corruption still occurs.  If this fixes the problem, 
then there is probably something in the reaper() (in yp_main.c) 
that is causing corruption, probably by ripping a structure out from
under whatever piece of code the signal happens to interrupt.

I took a quick look at the code and as far as I can tell it implements
no guards whatsoever.  The inetd code had similar problems in the past.

Alas, this is not something I have been able to reliably reproduce, it seems
to trigger itself every so-often (and at inconvienient times).  But no
matter what I do by myself it will not trip.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

spontaneous reboots in 4.0-STABLE (gotcha)

[David E. Cross]

Ok, I posted some panic messages awhile ago that appeared to go largely 
unnoticed.  I just got it again (this time while running in X) and I
was able to capture them via serial console.  I will separate this
message into 'fact', 'observation', and 'speculation':

Fact:

1) This was the same panic as before (when just running on console).
2) Panic is as follows:
 panic: clist reservation botch
 mp_lock = 0001; cpuid = 0; lapic.id = 0100
 Debugger("panic")
 panic: clist reservation botch
 mp_lock = 0003; cpuid = 0; lapic.id = 0100
 boot() called on cpu#0
 Uptime: 12h14m52s
 Automatic reboot in 15 seconds - press a key on the console to abort
 Rebooting...
 cpu_reset called on cpu#0
 cpu_reset: stopping other CPUs
3) This was running a -STABLE as of today
4) This is a SMP machine with SMP Kernel (2 CPUs)
5) Machine is USB, with USB console keyboard, USB mouse
6) attempting to 'control-alt-escape' into the debugger will sometimes hard-lock the 
system in the debugger mode.
7: running vinum on 1 SCSI and 2 IDE drives

Observations:
1) Appears much more likely if the system bus is busy
2) break to debugger hard-locking the system becomes more likely (to a 100%
   probability) the longer the system runs.  (this is measured in minutes,
   if I were to try to enter it now, 25minutes after boot, it would lock)

Speculations:
1) It appears to be a race condition of some sort in the USB code, perhaps
   not setting the correct SPL level before branching to the tty routines
   (for atkbdc it appears automagically set for you, with no such magic
   for USB that I can find)


If anyone needs additional information (configuration hasn't changed since the
earlier message), please ask.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

NFS FHs, what are they (how are they made?)

[David E. Cross]

I was previously under the impression that a NFS FH was basically a
concatenation of a device # and an inode #.  This was shot down earlier today.
The problem was that a disk had failed and we where doing a replacement (the
new disk was not identical to the old, it was substantially larger).  I
proceeded to format it so that the old fstab entry would work with the new
drive (that is the NFS exported partition would be called /dev/wd1s1h --
same device number, no?)  I then used dump/restore to ensure that the 
inode numbers would remain the same.  Making to further changes I shut down
the machine, swapped in the new drive and brought the system back up.  The
new drive was mounted faithfully by the old fstab.  Yet I now see 
"Stale NFS Handle"s on my clients.  What did I do wrong?

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: NFS FHs, what are they (how are they made?)

[David E. Cross]

D'oh.  My bad.  I think I am remembering this behaviour from SunOS days
past.

Oh Well.

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

lockd-0.2 released!

[David E. Cross]

I apologize profusely for the delay of this, but lockd-0.2 is out.
The URL is: http://www.cs.rpi.edu/~crossd/FreeBSD/lockd-0.2.tar.gz

A couple of notes on this release:

1) the statd hooks to lockd are not yet done (or started)

2) you need a patched libc (for XDR64 types).  I have included the xdr patch
   as part of this release, you need to do the following to apply it:
 cd /usr/src/lib/libc/xdr
 patch /path/to/lockd-0.2/xdr.diff

   (I hope this to make it into the base RSN)

3) you then need to rebuild and reinstall libc
4) build the lockd implementation and have fun
5) this does not add the code to FreeBSD's kernel to request the NFS locks
   (that is a job for people more skilled than I ;)

This has been tested with the test-suite provided by Mr. Gallatin.  There
are a number of tests that do not pass; they all relate to locking a 64bit
file on a NFSv2 mount; they all appear to be OS bugs on the NFS client side.
IRIX is particularly bad about this.

If you have any questions or comments please direct them to myself
[EMAIL PROTECTED]

--
David Cross   | email: [EMAIL PROTECTED] 
Lab Director  | Rm: 308 Lally Hall
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

rpc.lockd and xdr.

[David E. Cross]

Version 2 of the lock manager is ready to be released.  Amitha
says that it passes all of the tests in the suite posted by Drew (thanks
Drew).  A noteable exception to this is on SGI where some lock requests
are never even received from the remote host.  Also DOS sharing is not
yet complete.

On a side note, it would appear that at least some of the problems of the
previous version were in FreeBSD's XDR library.  The xdr_*_int64 routines
do not correctly do network byte order conversions.  Included below is
Amitha's 'hack fix'.


My hack fix (this is to /usr/src/lib/libc/xdr/xdr.c) is below. A similar
fix needs to be applied to xdr_int64_t. Note that xdr_opaque takes care of
swapping the bits in the byte.

#define SWAP(a,b,t) t=a;a=b;b=t

bool_t
my_xdr_u_int64_t(xdrs, uint64_p)
register XDR *xdrs;
u_int64_t *uint64_p;
{
u_int64_t x;
unsigned char* b= x;
unsigned char t;

switch (xdrs-x_op) {

case XDR_ENCODE:
SWAP(b[0], b[7], t);
SWAP(b[1], b[6], t);
SWAP(b[2], b[5], t);
SWAP(b[3], b[4], t);
return (xdr_opaque(xdrs, (caddr_t)uint64_p, sizeof(u_int64_t)))
;

case XDR_DECODE:
if (!xdr_opaque(xdrs, (caddr_t)x, sizeof x)) {
return (FALSE);
}
SWAP(b[0], b[7], t);
SWAP(b[1], b[6], t);
SWAP(b[2], b[5], t);
SWAP(b[3], b[4], t);
*uint64_p = x;
return (TRUE);

case XDR_FREE:
return (TRUE);
}
return (FALSE);
}

=

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: stuck NFS procs (LONG)

[David E. Cross]

Hmm... would this address the specific instances of our problems as well?
The two problems that we saw were a hard-locked machine, and the emacs
process in forever disk-wait.  The emacs binary would never have been in a
position to be truncated or modified at all when this problem happened.

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: stuck NFS procs (LONG)

[David E. Cross]

 Ah!... ok, it is an NFS bug.  I've been trying to track this down
 for a while ever since you reported the 3.4 lockup bug.  This is probably
 related to a similar problem. 
 
 There is a bug somewhere related to NFS locking up while doing a
 pagein from the executable image.   It can occur when the binary
 is ripped out from under the client but it also can apparently occur
 if the program takes a signal during a pagein on a valid binary
 that hasn't been ripped out.
 
 If you still have this machine up, can you idle it and do a tcpdump
 looking for NFS packets for a few minutes?  I'd like to know if it is
 doing an infinite retry of the page it got stuck on.  Knowing what
 it is trying to do and why it isn't aborting on error with a segfault
 is the key.
 
 After that, is there any chance you can panic this machine and get
 a kernel dump?

I can come close to idle... It should be realtively easy to identify the
NFS packets in question, they will be stale FH replies from the server
(as I pulled the backing store out from under it hoping that the retry would
trigger a SEGV).  Panic-ing it will be a bit trickier... the kernel is
compiled with DDB *BUT* the only console is a serial console and I forgot to
enable the ENABLE_DB_ON_SERIAL_BREAK thing-y.  I am sure with gdb -k
/kernel.debug /dev/mem and your expertise we could trip a panic somehow.

For now, let me get you that NFS packetlog...

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: stuck NFS procs (LONG)

[David E. Cross]

I just ran a tcpdump -s1500 for 5 minutes, gathered ~21k of data over that
time, no mentions of stale NFS handles from the NFS server... it would
appear the NFS client is not asking for those pages  (it makes sense, since if
it asked and got the 'stale' error one would expect the SEGV).

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

bpgetfile

[David E. Cross]

Solaris has this nifty little tool for querying the bootparam server on a
booting system.  Handy little gadget for getting various system configuration
at boot time.  Neither OpenBSD nor FreeBSD have it (FreeBSD has callbootd,
but I cannot get it to work easily), so I wrote a simple 'bpgetfile' for
the CSLab to use for some of our diskless systems.  The code is available
at http://www.cs.rpi.edu/~crossd/FreeBSD/bpgetfile.tar.gz

Have fun.
--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

stuck NFS procs

[David E. Cross]

This is only the second time ever this has happened, but it is still an
interesting problem... I have a large number of "emacs" processes stuck in 
disk-wait.  Here is the ps axl  line for one such process:

33639 88194 1   0 -22  0  5856  340 vmpfw  D qi-   0:01.34 emacs proxy.

Any attempt to access emacs on the client system would result in a type of
hang for that process.  Here is a 'cat /usr/local/bin/emacs /dev/null':

2371 90317 1   3 -18  0   2688 pgtblk D p4-   0:00.02 cat /usr/loc

To "fix" this I went to the NFS server and 'cp emacs emacs.new;rm emacs;mv emacs.new 
emacs'.  In essence forcing a new FH.  The old procs still stick arround.

This leads me to believe the problem is entirely on the local system (ie,
the kernel isn't asking for pages from the NFS server for that FH)

Any ideas what could be corrupting the local cache (I am assuming that is the
problem) like this.  Nothing of note in the dmesg.

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: stuck NFS procs (LONG)

[David E. Cross]

Ok... we'll start with the process table...

monica# ps axl | grep D
  UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT  TT   TIME COMMAND
0 0 0   0 -18  0 00 sched  DLs   ??0:00.81  (swapper)
0 2 0   0 -18  0 00 psleep DL??1:10.93  (pagedaemon
0 3 0  91  18  0 00 psleep DL??0:26.62  (vmdaemon)
0 4 0   0  18  0 00 syncer DL??1:51.82  (syncer)
17727 74079 1   0 -22  0  5952  340 vmpfw  D p4-   0:01.53 emacs websrv
17727 74586 1   0 -22  0  5952  340 vmpfw  D p4-   0:01.55 emacs websrv
33639 88342 1   0 -22  0  5856  340 vmpfw  D p4-   0:01.27 emacs proxy.
 2371 90317 1   3 -18  0   2688 pgtblk D p4-   0:00.02 cat /usr/loc
 2646 83637 1   0 -22  0  6256  528 vmpfw  D p9-   0:03.56 emacs
 2646 85055 1   0 -22  0  6344  528 vmpfw  D p9-   0:03.00 emacs
 2937 89546 1   0 -22  0  5576  340 vmpfw  D pa0:00.55 emacs /usr/t
 2575 75559 1   0 -22  0  5652  340 vmpfw  D pf-   0:00.99 emacs simple
 2575 78298 1   0 -22  0  5576  340 vmpfw  D pj-   0:00.97 emacs watchf
32837 85464 1   0 -22  0  6264  528 vmpfw  D pj-   0:02.81 emacs proj2.
32837 87204 1   0 -22  0  6264  528 vmpfw  D pj-   0:03.75 emacs proj2.
17727 90346 1   2 -22  0  5940  344 vmpfw  D pk-   0:01.23 emacs comm.c
 2575 76313 1   0 -22  0  5656  340 vmpfw  D pl-   0:01.54 emacs show_p
33355 84406 1   3 -22  0  7136  528 vmpfw  D pl-   0:04.54 emacs osshel
33355 85094 1   0 -22  0  7184  528 vmpfw  D pl-   0:04.52 emacs
17727 9 1   0 -22  0  5940  340 vmpfw  D pl-   0:01.17 emacs comm.c
0 64921 63848   0  10  0   476  292 ppwait D pt0:00.07 -su (csh)
 2551 75473 1   0 -22  0  7284  524 vmpfw  D q4-   0:05.27 emacs tftp_s
 2023 77402 1   0 -22  0  5672  340 vmpfw  D q8-   0:00.71 emacs index.
37080 7 1   0 -22  0  6208  524 vmpfw  D q8-   0:02.61 emacs bogosj
 2440 86790 1   0 -22  0  7176  524 vmpfw  D q9-   0:05.37 emacs bardet
 2440 88149 1   1 -22  0  7244  524 vmpfw  D q9-   0:04.91 emacs bardet
17727 89837 1   1 -22  0  5940  340 vmpfw  D qd-   0:01.13 emacs comm.c
33639 88194 1   0 -22  0  5856  340 vmpfw  D qi-   0:01.34 emacs proxy.


And we'll move on to some backtraces...

(kgdb) proc 74079
(kgdb) back
#0  mi_switch () at ../../kern/kern_synch.c:825
#1  0xc0131781 in tsleep (ident=0xc054b220, priority=0, 
wmesg=0xc0208bc2 "vmpfw", timo=0) at ../../kern/kern_synch.c:443
#2  0xc01cfa3f in vm_fault (map=0xca8028c0, vaddr=136036352, 
fault_type=3 '\003', fault_flags=8) at ../../vm/vm_fault.c:308
#3  0xc01ea17a in trap_pfault (frame=0xcac7ffbc, usermode=1, eva=136036368)
at ../../i386/i386/trap.c:816
#4  0xc01e9cca in trap (frame={tf_es = 136249383, tf_ds = -1078001625, 
  tf_edi = 400, tf_esi = 10, tf_ebp = -1078114780, tf_isp = -892862492, 
  tf_ebx = -1078110248, tf_edx = 136036332, tf_ecx = 137580544, 
  tf_eax = 1210023680, tf_trapno = 12, tf_err = 6, tf_eip = 134831395, 
  tf_cs = 31, tf_eflags = 66195, tf_esp = -1078114788, tf_ss = 39})
at ../../i386/i386/trap.c:358

(kgdb) proc 74586
(kgdb) back
#0  mi_switch () at ../../kern/kern_synch.c:825
#1  0xc0131781 in tsleep (ident=0xc054b220, priority=0, 
wmesg=0xc0208bc2 "vmpfw", timo=0) at ../../kern/kern_synch.c:443
#2  0xc01cfa3f in vm_fault (map=0xca6262c0, vaddr=136036352, 
fault_type=3 '\003', fault_flags=8) at ../../vm/vm_fault.c:308
#3  0xc01ea17a in trap_pfault (frame=0xcac58fbc, usermode=1, eva=136036368)
at ../../i386/i386/trap.c:816
#4  0xc01e9cca in trap (frame={tf_es = 39, tf_ds = 39, tf_edi = 2320, 
  tf_esi = 58, tf_ebp = -1078114780, tf_isp = -893022236, 
  tf_ebx = -1078108328, tf_edx = 136036332, tf_ecx = 137580544, 
  tf_eax = 1210023680, tf_trapno = 12, tf_err = 6, tf_eip = 134831395, 
  tf_cs = 31, tf_eflags = 66195, tf_esp = -1078114788, tf_ss = 39})
at ../../i386/i386/trap.c:358

(kgdb) proc 88342
(kgdb) back
#0  mi_switch () at ../../kern/kern_synch.c:825
#1  0xc0131781 in tsleep (ident=0xc054b220, priority=0, 
wmesg=0xc0208bc2 "vmpfw", timo=0) at ../../kern/kern_synch.c:443
#2  0xc01cfa3f in vm_fault (map=0xca801240, vaddr=136036352, 
fault_type=3 '\003', fault_flags=8) at ../../vm/vm_fault.c:308
#3  0xc01ea17a in trap_pfault (frame=0xca973fbc, usermode=1, eva=136036368)
at ../../i386/i386/trap.c:816
#4  0xc01e9cca in trap (frame={tf_es = 39, tf_ds = 39, tf_edi = 0, tf_esi = 0, 
  tf_ebp = -1078114664, tf_isp = -896057372, tf_ebx = -1078110532, 
  tf_edx = 136036332, tf_ecx = -1078110532, tf_eax = 1210023680, 
  tf_trapno = 12, tf_err = 6, tf_eip = 134831395, tf_cs = 31, 
  tf_eflags = 66195, tf_esp = -1078114672, tf_ss = 39})
at ../../i386/i386/trap.c:358

(this is the cat(1))
(kgdb) proc 90317
(kgdb) back
#0  mi_switch () at ../../kern/kern_synch.c:825

SBLive... anyone, anywhere?

[David E. Cross]

There was some mention in the SBLive earlier this year (January), whatever
became of it?  I checked www.posi.net and I do not see the driver listed
there at all.  Pointers/suggestions?

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

hard lock under 3.4-STABLE

[David E. Cross]

I am seeing a situation where a 3.4 system hard-locks while running 3.4
(hard lock being that it does not respond to its serial console, nor is
it pingable).  I believe (perhaps) that it may be NFS related, with a
program running on an NFS client when the executable itself is deleted
from the server  (although I haven't seen that style of panic in quite
some time, and it is usually has a couple of lines earlier in the output
to the effect that it lost its backing store. 

I realize that information is sparse in this, but that is because the
information that I have is equally sparse... I have no kernel messages,
I cannot drop into the kernel debugger, and no crashdump is ever created
(I need to hit the reset button to recover.)

I am trying to reproduce a test case, but it is difficult not knowing what
has caused the problems in the first place.

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

rpc.lockd... is done.

[David E. Cross]

Amitha (the person who has been working on the lockd code) has finished
most of his work.  There are still some issues with handling async locks 
and cancel messages.  Also we were not able to implement the full NLM
protocol as the FreeBSD kernel does not currently request NFS locks (we
should fix that ASAP).  This code is *ALPHA*.  Even we will not be running it
on production servers in the near future.

PS: the tarball is at
"http://www.cs.rpi.edu/~crossd/FreeBSD/lockd-2208.tar.gz"

PPS: I would like to set this up in CVS for everyone's ease, could someone
please tell em how to do this, and to make it available via cvsup?  (We
already have a complete FreeBSD cvsup mirror at cvsup.cs.rpi.edu, this
would just be another "module", right?
--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

rpc.lockd

[David E. Cross]

It is almost done.  A working and very lightly tested version of the code will
be made available on Monday (Jan 24).  It should be considered alpha quality,
I would not recommend running important NFS servers with this code.

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

PANIC in 3.4-STABLE

[David E. Cross]

I have found a reproduceable panic in recent 3.4-STABLE images (past couple
of weeks).  I am not sure how to reproduce it thought ;)  The panic occurs
in the tty code it would appear.  It is often preceded by strange TTY
behavior (strange characters suddenly appearing in the output, a randomly
closed connection, etc).  The panic message is:
 Panic: clist reservation botch
 mp_lock = 0001; cpuid = 1;
 lapic.id = 0100
 boot() called on cpu#0

As you can see, I am running SMP.  I also am extensively using vinum
(everything except for / is running off of multiple vinum stripes).  The
other custom setup on this box is that I have no atkdb* in my kernel, 
everything is through USB (flags 0x100 to device sc0).  The machine also
has 256MB of ECC RAM.

WILD GUESS FOLLOWS  I was reading through the various device drivers and
TTY code, and I noticed that much in tty_subr.c needs to be called at
spltty().  In the atkbd drive this is taken care of automagically since
it is declared as "tty" in the config file.  This is *not* done in the case
of 'device ukbd0'.  Furthermore within the keyboard driver itself 'spltty()'
is never called, only 'splusb()' (-- this may be enough?).  I am thinking
about adding some assert statements to the TTY code (or perhaps just a
printf()). and see what that turns up, but I do not know how to get the 
current spl().

This is not an easy bug to reproduce... In fact I cannot say 'do x, y, and z
to cause this panic.'  Yet it happens often enough to be consistent, part of
the reason I suspect a race condition.  Note that when the panic happens it
will not dump to a dumpdev, also 'control-alt-esc' with a USB keyboard seems
to not work right, the one time I tried I was unable to do anything.  I
seem to be able to get more panics/day by using my serial port at 115200,
heavily use the console, and be in X.

Any thoughts?

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

NLM v4 (file locking and NFS v3)

[David E. Cross]

We have come across a problem wrt to a network file lock manager.

Consider the case of a lock on a local file, and a request from a remote
machine to lock that same file.  fcntl(fd, F_SETLK, fl) will return
immediately with EAGAIN (this is for an exclusive case, of course), 
F_SETLKW will block (even if O_NONBLOCK has been set, this is annoying
even if documented behavior).  The question then becomes how is a user
process to tell when the lock has become available again?  Neither select(),
nor poll() seem to have the desired affect.  A couple possibilities that
have floated by are to have a select() with a 30 second timeout, at which
point scan the entire lock pending list.  Are there any other possibilities?

Also, could we get the fhopen, fhstat, and fhstatfs calls MFC-ed?  They appear
to be straightforward calls that do not depend on any VFS changes in -CURRENT.
Furthermore they are very special purpose, they only have the potential to
destabilize the system (if there are any bugs in them) if a program calls them.
As it stands I know of zero production programs that would call these
[nonexistent] syscalls :)

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Ok, that's it, enough is enough! (rpc.lockd)

[David E. Cross]

Ok... I have *had* it with the meta, but not really, lockd.  Are there any
kernel issues with correctly implimenting rpc.lockd?How can I take a
filehandle and map it into a filename, with path, so I may open it and lock
it on the server?  Are there any protocol specs?  I downloaded the RFC for 
version 4 nlm (which we do not supoprt at *all*), but it only lists diffs to
the version 3 spec, which I cannot find, and the source is not a whole lot
of help on this issue.

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: Ok, that's it, enough is enough! (rpc.lockd)

[David E. Cross]

Does NetBSD have a working rpc.lockd... that would make this much easier.

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

wacky rpc.lockd idea...

[David E. Cross]

I've noticed about 99% of the panics on our machines are the result of NFS, 
more often than not it is the result of a backing store file being blown
away underneath the client.  ie.  person editing a file on one machine, 
compiling and running on a second, then removing the binary on the first
machine.  If we had a working lock manager could we not have the kernel open
a shared lock on anything it had in backing store, would that not assure that
files didn't go poof in the night?

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

AMD wedging

[David E. Cross]

I have been noticing of late a disturbing trend of AMD wedging and
eventually taking the entire system down.  The WCHAN that it is locked in is
"sbwait".  I now have the luxury of having this happen on a non-critical
system with DDB compiled in (the system is the one I am typing on now).
How would I go about finding exactly what it is stuck on so I may correct
the bug in the kernel or amd?

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

3.3-STABLE panic

[David E. Cross]

I received the following panic() on our primary user fileserver.  Note that
this is the first panic we have received in well over 80 days.

Below is a backtrace obtained from a kernel with debugging symbols:

IdlePTD 2977792
initial pcb at 264d38
panicstr: softdep_lock: locking against myself
panic messages:
---
panic: allocdirect_check: old 0 != new 1225576 || lbn 13 = 12

syncing disks... panic: softdep_lock: locking against myself

dumping to dev 30001, offset 851968
dump 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 
68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 
10 9 8 7 6 5 4 3 2 1 
---
#0  boot (howto=260) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0  boot (howto=260) at ../../kern/kern_shutdown.c:285
#1  0xc014f429 in panic (fmt=0xc023bd04 "softdep_lock: locking against myself")
at ../../kern/kern_shutdown.c:446
#2  0xc01dc3bd in acquire_lock (lk=0xc0258214)
at ../../ufs/ffs/ffs_softdep.c:266
#3  0xc01dfd71 in softdep_update_inodeblock (ip=0xc0d9ed00, bp=0xc2befa00, 
waitfor=0) at ../../ufs/ffs/ffs_softdep.c:3447
#4  0xc01db40c in ffs_update (vp=0xc6700f40, waitfor=0)
at ../../ufs/ffs/ffs_inode.c:105
#5  0xc01e2e2c in ffs_sync (mp=0xc0cedc00, waitfor=2, cred=0xc0690300, 
p=0xc027ce0c) at ../../ufs/ffs/ffs_vfsops.c:1001
#6  0xc0175ff7 in sync (p=0xc027ce0c, uap=0x0) at ../../kern/vfs_syscalls.c:549
#7  0xc014efd1 in boot (howto=256) at ../../kern/kern_shutdown.c:203
#8  0xc014f429 in panic (
fmt=0xc023c124 "allocdirect_check: old %d != new %d || lbn %ld = %d")
at ../../kern/kern_shutdown.c:446
#9  0xc01dd373 in allocdirect_merge (adphead=0xc10761c4, newadp=0xc10b5980, 
oldadp=0xc10bdb00) at ../../ufs/ffs/ffs_softdep.c:1238
#10 0xc01dff45 in merge_inode_lists (inodedep=0xc1076180)
at ../../ufs/ffs/ffs_softdep.c:3523
#11 0xc01dfe03 in softdep_update_inodeblock (ip=0xc0e31100, bp=0xc2c562b8, 
waitfor=1) at ../../ufs/ffs/ffs_softdep.c:3471
#12 0xc01db40c in ffs_update (vp=0xc68ebd80, waitfor=1)
at ../../ufs/ffs/ffs_inode.c:105
#13 0xc01e40cb in ffs_write (ap=0xc6708c7c)
at ../../ufs/ufs/ufs_readwrite.c:508
#14 0xc01a8775 in nfsrv_write (nfsd=0xc1017100, slp=0xc0cf7300, 
procp=0xc66beb20, mrq=0xc6708e34) at vnode_if.h:331
#15 0xc01be8a6 in nfssvc_nfsd (nsd=0xc6708e94, argp=0x8071f04 "", p=0xc66beb20)
at ../../nfs/nfs_syscalls.c:656
#16 0xc01be1c1 in nfssvc (p=0xc66beb20, uap=0xc6708f94)
at ../../nfs/nfs_syscalls.c:342
#17 0xc0213c0b in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 8, 
  tf_esi = 0, tf_ebp = -1077944892, tf_isp = -965701660, tf_ebx = 0, 
  tf_edx = -1077945288, tf_ecx = 0, tf_eax = 155, tf_trapno = 12, 
  tf_err = 2, tf_eip = 134518972, tf_cs = 31, tf_eflags = 642, 
  tf_esp = -1077945280, tf_ss = 39}) at ../../i386/i386/trap.c:1100
#18 0xc0208e7c in Xint0x80_syscall ()
#19 0x80480e9 in ?? ()

--
David Cross   | email: [EMAIL PROTECTED] 
Acting Lab Director   | NYSLP: FREEBSD
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: missing files with NFSv3 and Solaris2.7 machine...

[David E. Cross]

  We have a number of solaris 2.78 machines (I am in the process of installing
  them now), and I notice that if I ls a directory that is mounted NFSv3/UDP from
  a FreeBSD server to a Solaris 2.7 client there are a number of files that
  show up missing.  This is most intreaging with a large untar as I can do
  'ls | wc -l' in a directory and watch the numbers dance:
 
 ...
  
  Any ideas what isn't working correctly?
 
 This looks like something that was discussed maybe a couple of
 months ago. It turned out to be a bug in the Solaris implementation,
 which is something some people did not accept because the Solaris
 implementation is the reference implementation (yeah, I'll call all
 my programs "reference implementation" from now on :). FreeBSD is
 working according to NFS specs, but Solaris isn't.

Count me as one of the ones who do not accept this answer.  I realize that
the Sun code may very well have bugs in it.  I also know that what we have
right now "doesn't work" with sun clients.  I believe that we have made
modifications to our TCP/IP stack  code to deal with windows machines who
are not to spec, could we not do the same for sun and NFS?

Alternately, we have a sun support contract, and if someone could detail to
me exactly how they are not compliant I will try to file a bug report.

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

missing files with NFSv3 and Solaris2.7 machine...

[David E. Cross]

We have a number of solaris 2.78 machines (I am in the process of installing
them now), and I notice that if I ls a directory that is mounted NFSv3/UDP from
a FreeBSD server to a Solaris 2.7 client there are a number of files that
show up missing.  This is most intreaging with a large untar as I can do
'ls | wc -l' in a directory and watch the numbers dance:

*e inbox $ ls | wc -l 
 668
*e inbox $ ls | wc -l
 710
*e inbox $ ls | wc -l
 794
*e inbox $ ls | wc -l
 248
*e inbox $ ls | wc -l
 836


Any ideas what isn't working correctly?

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

perl stangeness on 3.3-RC

[David E. Cross]

We have a very hetergenous environment here (even among the FreeBSD boxes).
Each PC tends to be just a little bit different.  This expecially causes
problems since we wish to have XDM on each machine on boot and have X
on a NFS partition.  TO alleviate this we invented a simple Perl script
to replace /usr/X11R6/bin/X to run the correct program on each machine:


#!/usr/bin/perl -w
use Sys::Hostname;

read_servers();
$commandline="/usr/X11R6/bin/XF86_VGA16";
$host=hostname();
print STDERR "host is $host\n";
$screen=$ARGV[0];
$display= $host . $screen;
print STDERR "display is $display\n";
if ($server{$display}) {
 $commandline = join (' ', $server{$display}, @ARGV);
}
elsif ($server{$host}) {
 $commandline = join (' ',$server{$host}, @ARGV);
}
exec $commandline;

sub read_servers {
 open (XSERVERLIST, "/usr/local/etc/xservers");
 while ($hostline = XSERVERLIST) {
  chomp ($hostline);
  @fields = split ' ', $hostline, 2;
  $server{$fields[0]} = $fields[1];
 }
}

This worked fine up until about 3.3-RC, then it stopped with the following
error:

Use of uninitialized value at /usr/libdata/perl/5.00503/Sys/Hostname.pm line 100, 
XSERVERLIST chunk 13.
Use of uninitialized value at /usr/libdata/perl/5.00503/Sys/Hostname.pm line 109, 
XSERVERLIST chunk 13.
Can't exec "/com/host": No such file or directory at 
/usr/libdata/perl/5.00503/Sys/Hostname.pm line 115, XSERVERLIST chunk 13.
Cannot get host name of local machine at /usr/X11R6/bin/X line 6

Note that this is *only* a problem when this script is run by xdm by init.
If I run the script by hand, or I run xdm by hand it works OK.  Also consider
the results of a ktrace on init (PID 1) when xdm was started (alot of stuff
has been deleted to ease readability:


   445 perl RET   execve 0

   445 perl forks and execs 'hostname'

   447 hostname RET   execve 0
   447 hostname CALL  __sysctl(0xbfbfdcd0,0x2,0xbfbfdcf8,0xbfbfdcd8,0,0)
   447 hostname RET   __sysctl 0
   447 hostname CALL  fstat(0x1,0xbfbfd9e4)
   447 hostname RET   fstat 0
   447 hostname CALL  readlink(0x8050a1c,0xbfbfd9e4,0x3f)
   447 hostname NAMI  "/etc/malloc.conf"
   447 hostname RET   readlink -1 errno 2 No such file or directory
   447 hostname CALL  mmap(0,0x1000,0x3,0x1002,0x,0,0,0)
   447 hostname RET   mmap 671424512/0x28052000
   447 hostname CALL  break(0x8055000)
   447 hostname RET   break 0
   447 hostname CALL  break(0x8059000)
   447 hostname RET   break 0
   447 hostname CALL  write(0x1,0x8055000,0x10)
   447 hostname GIO   fd 1 wrote 16 bytes
   "loot.cs.rpi.edu
   "
   445 perl GIO   fd 1 read 16 bytes
   "loot.cs.rpi.edu
   "
   445 perl RET   read 16/0x10
   445 perl CALL  read(0x1,0x80e,0x4000)
   447 hostname RET   write 16/0x10
   447 hostname CALL  exit(0)
   446 sh   RET   wait4 447/0x1bf
   446 sh   CALL  exit(0)
   445 perl GIO   fd 1 read 0 bytes
   ""
   445 perl RET   read 0
   445 perl CALL  close(0x1)
   445 perl RET   close 0
   445 perl GIO   fd 2 wrote 106 bytes
   "Use of uninitialized value at /usr/libdata/perl/5.00503/Sys/Hostname.p\
m line 100, XSERVERLIST chunk 13.
   "
.
.
.
   448 sh   NAMI  "/bin/uname"
   448 sh   RET   stat -1 errno 2 No such file or directory
   448 sh   CALL  stat(0x809ccb8,0xbfbfdc54)
   448 sh   NAMI  "/usr/bin/uname"
   448 sh   RET   stat 0
   448 sh   CALL  break(0x80a3000)

.
.
.

   449 unameRET   execve 0
   449 unameGIO   fd 1 wrote 16 bytes
   "loot.cs.rpi.edu
   "
   445 perl GIO   fd 1 read 16 bytes
   "loot.cs.rpi.edu
   "
   448 sh   RET   wait4 449/0x1c1
   448 sh   CALL  exit(0)
   445 perl GIO   fd 1 read 0 bytes
   ""
   445 perl RET   read 0
   445 perl CALL  close(0x1)
   445 perl RET   close 0
   445 perl GIO   fd 2 wrote 106 bytes
   "Use of uninitialized value at /usr/libdata/perl/5.00503/Sys/Hostname.p\
m line 109, XSERVERLIST chunk 13.
   "
   450 perl CALL  execve(0x80dd140,0x808c2e0,0x8076e80)
   450 perl NAMI  "/com/host"
   450 perl RET   execve -1 errno 2 No such file or directory
   450 perl CALL  write(0x2,0x8070e00,0x81)
   450 perl GIO   fd 2 wrote 129 bytes
   "Can't exec "/com/host": No such file or directory at /usr/libdata/perl\
/5.00503/Sys/Hostname.pm line 115, XSERVERLIST chunk 13.
   "
   450 perl RET   write 129/0x81
   450 perl CALL  exit(0x1)
   "Cannot get host name of local machine at /usr/X11R6/bin/X line 6
   "

Any ideas what is going on here?  It looks like it gets what it wants and then
just ignores it?!?

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I 

Re: softupdates panic in 3.3-RC

[David E. Cross]

 Softupdates has known bugs relating to filesystem full conditions which
 I believe Kirk is working on.  There isn't much you can do until then
 other then either disable softupdates or work to avoid the disk-full 
 condition.  The panic does not occur very frequently so working
 to avoid the disk-full condition is what I would recommend.

Ok, sort-a what I figured.  Thanks.

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: perl stangeness on 3.3-RC

[David E. Cross]

 Umm, you can edit /usr/X11R6/lib/X11/xdm/Xservers to configure xdm to
 run say /usr/config/X (which would be stored on the local machiens hard
 drive) instead of /usr/X11R6/bin/X.  This is a much simpler solution.
 :)  (Just symlink /usr/config/X to /usr/X11R6/bin/XF86_Whatever.)

Simpler?  It has modifications made on each machine rather in one file in 
a central location.  Plus many things expect to find /usr/X11R6/bin/X
(ala startx and xinit), and we use this on multiple architectures, and some
network/diskless booting systems where mutliple machines share the same
root partition.   This is kinda moot however, since I am more interested in
what caused it to stop working in the first place.  It really seems to be an
a bug.  At glancing through the perl module that does this (Sys/hostname.pm)
it would appear that there is no PATH environ variable set when init is run,
and that is causing the last statemnt in each function block to fail, thus
making the whole block fail.  It is interesting however that the syscall
method isn't working.  FreeBSD doesn't have a gethostname _system_ call, but
it does have the gethostname() library call (which uses sysctl(2)).  Any
ideas how to get perl to use this?

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

perl stangeness on 3.3-RC

[David E. Cross]

We have a very hetergenous environment here (even among the FreeBSD boxes).
Each PC tends to be just a little bit different.  This expecially causes
problems since we wish to have XDM on each machine on boot and have X
on a NFS partition.  TO alleviate this we invented a simple Perl script
to replace /usr/X11R6/bin/X to run the correct program on each machine:


#!/usr/bin/perl -w
use Sys::Hostname;

read_servers();
$commandline=/usr/X11R6/bin/XF86_VGA16;
$host=hostname();
print STDERR host is $host\n;
$screen=$ARGV[0];
$display= $host . $screen;
print STDERR display is $display\n;
if ($server{$display}) {
 $commandline = join (' ', $server{$display}, @ARGV);
}
elsif ($server{$host}) {
 $commandline = join (' ',$server{$host}, @ARGV);
}
exec $commandline;

sub read_servers {
 open (XSERVERLIST, /usr/local/etc/xservers);
 while ($hostline = XSERVERLIST) {
  chomp ($hostline);
  @fields = split ' ', $hostline, 2;
  $server{$fields[0]} = $fields[1];
 }
}

This worked fine up until about 3.3-RC, then it stopped with the following
error:

Use of uninitialized value at /usr/libdata/perl/5.00503/Sys/Hostname.pm line 
100, XSERVERLIST chunk 13.
Use of uninitialized value at /usr/libdata/perl/5.00503/Sys/Hostname.pm line 
109, XSERVERLIST chunk 13.
Can't exec /com/host: No such file or directory at 
/usr/libdata/perl/5.00503/Sys/Hostname.pm line 115, XSERVERLIST chunk 13.
Cannot get host name of local machine at /usr/X11R6/bin/X line 6

Note that this is *only* a problem when this script is run by xdm by init.
If I run the script by hand, or I run xdm by hand it works OK.  Also consider
the results of a ktrace on init (PID 1) when xdm was started (alot of stuff
has been deleted to ease readability:


   445 perl RET   execve 0

   445 perl forks and execs 'hostname'

   447 hostname RET   execve 0
   447 hostname CALL  __sysctl(0xbfbfdcd0,0x2,0xbfbfdcf8,0xbfbfdcd8,0,0)
   447 hostname RET   __sysctl 0
   447 hostname CALL  fstat(0x1,0xbfbfd9e4)
   447 hostname RET   fstat 0
   447 hostname CALL  readlink(0x8050a1c,0xbfbfd9e4,0x3f)
   447 hostname NAMI  /etc/malloc.conf
   447 hostname RET   readlink -1 errno 2 No such file or directory
   447 hostname CALL  mmap(0,0x1000,0x3,0x1002,0x,0,0,0)
   447 hostname RET   mmap 671424512/0x28052000
   447 hostname CALL  break(0x8055000)
   447 hostname RET   break 0
   447 hostname CALL  break(0x8059000)
   447 hostname RET   break 0
   447 hostname CALL  write(0x1,0x8055000,0x10)
   447 hostname GIO   fd 1 wrote 16 bytes
   loot.cs.rpi.edu
   
   445 perl GIO   fd 1 read 16 bytes
   loot.cs.rpi.edu
   
   445 perl RET   read 16/0x10
   445 perl CALL  read(0x1,0x80e,0x4000)
   447 hostname RET   write 16/0x10
   447 hostname CALL  exit(0)
   446 sh   RET   wait4 447/0x1bf
   446 sh   CALL  exit(0)
   445 perl GIO   fd 1 read 0 bytes
   
   445 perl RET   read 0
   445 perl CALL  close(0x1)
   445 perl RET   close 0
   445 perl GIO   fd 2 wrote 106 bytes
   Use of uninitialized value at /usr/libdata/perl/5.00503/Sys/Hostname.p\
m line 100, XSERVERLIST chunk 13.
   
.
.
.
   448 sh   NAMI  /bin/uname
   448 sh   RET   stat -1 errno 2 No such file or directory
   448 sh   CALL  stat(0x809ccb8,0xbfbfdc54)
   448 sh   NAMI  /usr/bin/uname
   448 sh   RET   stat 0
   448 sh   CALL  break(0x80a3000)

.
.
.

   449 unameRET   execve 0
   449 unameGIO   fd 1 wrote 16 bytes
   loot.cs.rpi.edu
   
   445 perl GIO   fd 1 read 16 bytes
   loot.cs.rpi.edu
   
   448 sh   RET   wait4 449/0x1c1
   448 sh   CALL  exit(0)
   445 perl GIO   fd 1 read 0 bytes
   
   445 perl RET   read 0
   445 perl CALL  close(0x1)
   445 perl RET   close 0
   445 perl GIO   fd 2 wrote 106 bytes
   Use of uninitialized value at /usr/libdata/perl/5.00503/Sys/Hostname.p\
m line 109, XSERVERLIST chunk 13.
   
   450 perl CALL  execve(0x80dd140,0x808c2e0,0x8076e80)
   450 perl NAMI  /com/host
   450 perl RET   execve -1 errno 2 No such file or directory
   450 perl CALL  write(0x2,0x8070e00,0x81)
   450 perl GIO   fd 2 wrote 129 bytes
   Can't exec /com/host: No such file or directory at /usr/libdata/perl\
/5.00503/Sys/Hostname.pm line 115, XSERVERLIST chunk 13.
   
   450 perl RET   write 129/0x81
   450 perl CALL  exit(0x1)
   Cannot get host name of local machine at /usr/X11R6/bin/X line 6
   

Any ideas what is going on here?  It looks like it gets what it wants and then
just ignores it?!?

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  

Re: softupdates panic in 3.3-RC

[David E. Cross]

 Softupdates has known bugs relating to filesystem full conditions which
 I believe Kirk is working on.  There isn't much you can do until then
 other then either disable softupdates or work to avoid the disk-full 
 condition.  The panic does not occur very frequently so working
 to avoid the disk-full condition is what I would recommend.

Ok, sort-a what I figured.  Thanks.

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

Re: perl stangeness on 3.3-RC

[David E. Cross]

 Umm, you can edit /usr/X11R6/lib/X11/xdm/Xservers to configure xdm to
 run say /usr/config/X (which would be stored on the local machiens hard
 drive) instead of /usr/X11R6/bin/X.  This is a much simpler solution.
 :)  (Just symlink /usr/config/X to /usr/X11R6/bin/XF86_Whatever.)

Simpler?  It has modifications made on each machine rather in one file in 
a central location.  Plus many things expect to find /usr/X11R6/bin/X
(ala startx and xinit), and we use this on multiple architectures, and some
network/diskless booting systems where mutliple machines share the same
root partition.   This is kinda moot however, since I am more interested in
what caused it to stop working in the first place.  It really seems to be an
a bug.  At glancing through the perl module that does this (Sys/hostname.pm)
it would appear that there is no PATH environ variable set when init is run,
and that is causing the last statemnt in each function block to fail, thus
making the whole block fail.  It is interesting however that the syscall
method isn't working.  FreeBSD doesn't have a gethostname _system_ call, but
it does have the gethostname() library call (which uses sysctl(2)).  Any
ideas how to get perl to use this?

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

softupdates panic in 3.3-RC

[David E. Cross]

Our ftp server crashed early this morning with what appears to be a softupdates
error:

 Sep 13 09:56:19 stumble /kernel: pid 41477 (perl), uid 0 on /exports/share3/ftp/.2: 
file system full
 
 panic: softdep_write_inodeblock: indirect pointer #0 mismatch 0 != 15597568
 syncing disks... panic: softdep_lock: locking against myself

'perl' would have been the nightly mirror(1) run to sync up our ftp site.

What additional details would be usefull?  We didn't have crashdumps enabled
on this machine, so a backtrace is not fully possible, although it would seem
the contextual evidence for what went wrong is strong.

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

softupdates panic in 3.3-RC

[David E. Cross]

Our ftp server crashed early this morning with what appears to be a softupdates
error:

 Sep 13 09:56:19 stumble /kernel: pid 41477 (perl), uid 0 on 
 /exports/share3/ftp/.2: file system full
 
 panic: softdep_write_inodeblock: indirect pointer #0 mismatch 0 != 15597568
 syncing disks... panic: softdep_lock: locking against myself

'perl' would have been the nightly mirror(1) run to sync up our ftp site.

What additional details would be usefull?  We didn't have crashdumps enabled
on this machine, so a backtrace is not fully possible, although it would seem
the contextual evidence for what went wrong is strong.

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

panic.. 3.2-STABLE-OLD...

[David E. Cross]

Well, it has been a long time since I have needed to write an email with that
tagline.  Our primary NFS server had been up for almost 2 months with no
panics.  We did need to reboot it for a network change, but it was up for 28
days at that point.  Anyway here are the details:

dev = 0x20014, block = 2096, fs = /exports/home3
panic: ffs_blkfree: freeing free block
#0  0xc014b6cb in boot ()
#1  0xc014b950 in at_shutdown ()
#2  0xc01d50ef in ffs_blkfree ()
#3  0xc01d992c in indir_trunc ()
#4  0xc01d9688 in handle_workitem_freeblocks ()
#5  0xc01d7c28 in softdep_process_worklist ()
#6  0xc016f9b4 in sched_sync ()
#7  0xc013e56a in kproc_start ()
#8  0xc020328a in fork_trampoline ()

  UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT  TT   TIME COMMAND
0 0 0   0 -18  0 00 sched  DLs   ??0:00.00  (swapper)
0 1 0   0  10  0   4960 wait   Is??0:00.00  (init)
0 2 0   0 -18  0 00 -  RL??0:00.00  (pagedaemon
0 3 0   0  18  0 00 psleep DL??0:00.00  (vmdaemon)
0 4 0 272  -6  0 00 -  RL??0:00.00  (syncer)
042 1   0  10  0 2629000 mfsidl ILs   ??0:00.00  (mount_mfs)
0   140 1   0   2  0   8160 -  Rs??0:00.00  (syslogd)
0   150 1  14   2 -12  10480 -  Rs   ??0:00.00  (xntpd)
1   155 1   0   2  0   8360 select Is??0:00.00  (portmap)
0   158 1   0   2  0  15480 -  Rs??0:00.00  (ypserv)
0   163 1   0   2  0   8040 select Is??0:00.00  (ypbind)
0   176 1   0   2  0   8720 select Is??0:00.00  (mountd)
0   179 1   0   2  0   3160 accept Is??0:00.00  (nfsd)
0   181   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   182   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   183   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   184   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   185   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   186   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   187   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   188   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   191 1   0   2  0 2629680 select Is??0:00.00  (rpc.statd)
0   196 1   0  10  0   2080 nfsidl I ??0:00.00  (nfsiod)
0   197 1   0  10  0   2080 nfsidl I ??0:00.00  (nfsiod)
0   198 1   0  10  0   2080 nfsidl I ??0:00.00  (nfsiod)
0   199 1  20  10  0   2080 nfsidl I ??0:00.00  (nfsiod)
0   205 1   0   2  0  15960 select Ss??0:00.00  (amd)
0   233 1   0   2  0   8880 select Is??0:00.00  (inetd)
0   236 1   4  10  0   9840 nanslp Is??0:00.00  (cron)
0   337 1   0   2  0  12760 select Is??0:00.00  (sshd2)
0   390   233   0   2  0  14520 -  Rs??0:00.00  (nmbd)
0 71340   233   0   2  0  30800 -  Rs??0:00.00  (smbd)
0 76993   337   0   2  0  13760 select I ??0:00.00  (sshd2)
0 77721   337   0   2  0  13760 select I ??0:00.00  (sshd2)
 2717 77002 76993   0   3  0  14840 ttyin  Is+   p00:00.00  (bash)
0 77008 77002   0  28  0  14880 -  T p00:00.00  (bash)
 2717 77722 77721   0   3  0  14840 ttyin  Is+   p10:00.00  (bash)
0 77727 77722   0  28  0  14880 -  T p10:00.00  (bash)
0   378 1   0   3  0   8240 ttyin  Is+   v00:00.00  (getty)
0   379 1   0   3  0   8240 ttyin  Is+   v10:00.00  (getty)
0   380 1   0   3  0   8240 ttyin  Is+   v20:00.00  (getty)
0   377 1   0   3  0   8240 ttyin  Is+   d00:00.00  (getty)

FreeBSD stagger.cs.rpi.edu 3.2-STABLE FreeBSD 3.2-STABLE #0: Fri Jul 30 23:32:30 EDT 
1999 [EMAIL PROTECTED]:/usr/src/sys/compile/STAGGER  i386

And we are running with softupdates.

Additional details can be provided, this is all I can think of at the moment.

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

panic.. 3.2-STABLE-OLD...

[David E. Cross]

Well, it has been a long time since I have needed to write an email with that
tagline.  Our primary NFS server had been up for almost 2 months with no
panics.  We did need to reboot it for a network change, but it was up for 28
days at that point.  Anyway here are the details:

dev = 0x20014, block = 2096, fs = /exports/home3
panic: ffs_blkfree: freeing free block
#0  0xc014b6cb in boot ()
#1  0xc014b950 in at_shutdown ()
#2  0xc01d50ef in ffs_blkfree ()
#3  0xc01d992c in indir_trunc ()
#4  0xc01d9688 in handle_workitem_freeblocks ()
#5  0xc01d7c28 in softdep_process_worklist ()
#6  0xc016f9b4 in sched_sync ()
#7  0xc013e56a in kproc_start ()
#8  0xc020328a in fork_trampoline ()

  UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT  TT   TIME COMMAND
0 0 0   0 -18  0 00 sched  DLs   ??0:00.00  (swapper)
0 1 0   0  10  0   4960 wait   Is??0:00.00  (init)
0 2 0   0 -18  0 00 -  RL??0:00.00  (pagedaemon
0 3 0   0  18  0 00 psleep DL??0:00.00  (vmdaemon)
0 4 0 272  -6  0 00 -  RL??0:00.00  (syncer)
042 1   0  10  0 2629000 mfsidl ILs   ??0:00.00  (mount_mfs)
0   140 1   0   2  0   8160 -  Rs??0:00.00  (syslogd)
0   150 1  14   2 -12  10480 -  Rs   ??0:00.00  (xntpd)
1   155 1   0   2  0   8360 select Is??0:00.00  (portmap)
0   158 1   0   2  0  15480 -  Rs??0:00.00  (ypserv)
0   163 1   0   2  0   8040 select Is??0:00.00  (ypbind)
0   176 1   0   2  0   8720 select Is??0:00.00  (mountd)
0   179 1   0   2  0   3160 accept Is??0:00.00  (nfsd)
0   181   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   182   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   183   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   184   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   185   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   186   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   187   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   188   179   0   2  0   2960 -  R ??0:00.00  (nfsd)
0   191 1   0   2  0 2629680 select Is??0:00.00  (rpc.statd)
0   196 1   0  10  0   2080 nfsidl I ??0:00.00  (nfsiod)
0   197 1   0  10  0   2080 nfsidl I ??0:00.00  (nfsiod)
0   198 1   0  10  0   2080 nfsidl I ??0:00.00  (nfsiod)
0   199 1  20  10  0   2080 nfsidl I ??0:00.00  (nfsiod)
0   205 1   0   2  0  15960 select Ss??0:00.00  (amd)
0   233 1   0   2  0   8880 select Is??0:00.00  (inetd)
0   236 1   4  10  0   9840 nanslp Is??0:00.00  (cron)
0   337 1   0   2  0  12760 select Is??0:00.00  (sshd2)
0   390   233   0   2  0  14520 -  Rs??0:00.00  (nmbd)
0 71340   233   0   2  0  30800 -  Rs??0:00.00  (smbd)
0 76993   337   0   2  0  13760 select I ??0:00.00  (sshd2)
0 77721   337   0   2  0  13760 select I ??0:00.00  (sshd2)
 2717 77002 76993   0   3  0  14840 ttyin  Is+   p00:00.00  (bash)
0 77008 77002   0  28  0  14880 -  T p00:00.00  (bash)
 2717 77722 77721   0   3  0  14840 ttyin  Is+   p10:00.00  (bash)
0 77727 77722   0  28  0  14880 -  T p10:00.00  (bash)
0   378 1   0   3  0   8240 ttyin  Is+   v00:00.00  (getty)
0   379 1   0   3  0   8240 ttyin  Is+   v10:00.00  (getty)
0   380 1   0   3  0   8240 ttyin  Is+   v20:00.00  (getty)
0   377 1   0   3  0   8240 ttyin  Is+   d00:00.00  (getty)

FreeBSD stagger.cs.rpi.edu 3.2-STABLE FreeBSD 3.2-STABLE #0: Fri Jul 30 
23:32:30 EDT 1999 r...@phoenix.cs.rpi.edu:/usr/src/sys/compile/STAGGER  i386

And we are running with softupdates.

Additional details can be provided, this is all I can think of at the moment.

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

Tulip device driver question

[David E. Cross]

I am modifying the tulip device driver to support this xircom card.  I have it
almost entirely working, *except* that it goes into infinite re-neogitiate
loops.  The card probes correctly at bootup, but any attempt to change 
information via ifconfig ("ifconfig de0 inet ..." and "ifconfig de0 up",
and "ifconfig de0 media 10baseTX" will all do it)  results in it probing,
then resetting, then probing again. over and over in an infinite loop.  
Ideas?

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Tulip device driver question

[David E. Cross]

I am modifying the tulip device driver to support this xircom card.  I have it
almost entirely working, *except* that it goes into infinite re-neogitiate
loops.  The card probes correctly at bootup, but any attempt to change 
information via ifconfig (ifconfig de0 inet ... and ifconfig de0 up,
and ifconfig de0 media 10baseTX will all do it)  results in it probing,
then resetting, then probing again. over and over in an infinite loop.  
Ideas?

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

device_add_child??

[David E. Cross]

I have been writing a nasty kludge to treat a CardBus bridge as a standard
PCI bridge (with static config)  you may start throwing rocks now.  I have
it to the point where I can (after the system is booted) 'pciconf -r
pci5:0:0 0' and get scan information (neat, huh :).  Welll, I thought it would
then just be a simple matter of 'device_add_child(dev, pci, 5, 0);' to get
the bus to show up at PCI5: at bootup, but it seems to ignore it.  following
from pcisupport.c I also tried to 'bus_generic_attach()' it after
device_add_child() finished.  no go.  Any suggestions?

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

CDROM boot on a ThinkPad 600E...

[David E. Cross]

I have been attempting to track down why cdrom boots will not work with
/boot/loader, but do just fine with the boot-block.  I have come to the 
following wild speculation, and stab in the dark.  /boot/loader uses some
int13 stuff, which I found while reading in the boot0inst man page may cause
trouble on certain machines.  I believe this may be our smoking gun, but I lack
the time and experience to actually track it down.

I could use boot0cfg to set 'packet' mode, but I am affraid that by doing so
I may loose all access to my machine and need to attack it with a boot floppy.

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

CDROM boot on a ThinkPad 600E...

[David E. Cross]

I have been attempting to track down why cdrom boots will not work with
/boot/loader, but do just fine with the boot-block.  I have come to the 
following wild speculation, and stab in the dark.  /boot/loader uses some
int13 stuff, which I found while reading in the boot0inst man page may cause
trouble on certain machines.  I believe this may be our smoking gun, but I lack
the time and experience to actually track it down.

I could use boot0cfg to set 'packet' mode, but I am affraid that by doing so
I may loose all access to my machine and need to attack it with a boot floppy.

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

PCI programming woes.

[David E. Cross]

I am trying to write a very kludgey/monolithic driver for a CardBus ethernet
adapter.  I have run into a bit of a stumbling block on some issues.  One such
issue is the attach (I need to map some registers of the adapter into memory
space so I can read/write values.).  Anyway if someone could explain some
of the following I would be very thankfull.

Take your average run-to-the mill PCI network driver... like FPA or FXP.  Now
look for the attach routines... there are *2* of them, with the exact same
function name, and different arguments?!?!

Huh, what is going on here?  Help?

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

Re: Kerberos 5 integration.

[David E. Cross]

I offered (to Theo T'So) before our (Computer Science Department at RPI)
resources to setup a RO CVS repo for Kerberos V.  He accepted out offer
but things stagnated after that on setting up the details.  My fault mostly
for not taking the tourch that has been passed.  I am [now] offering
again, and I think we can do it.  If someone can contact me we can get this
setup ASAP.

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: Kerberos 5 integration.

[David E. Cross]

I am terribly sorry.  I had 2 messages about kerboers5 come in at the same
time (one from -hackers, one from mit), I replied to to wrong one.

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: Kerberos 5 integration.

[David E. Cross]

I offered (to Theo T'So) before our (Computer Science Department at RPI)
resources to setup a RO CVS repo for Kerberos V.  He accepted out offer
but things stagnated after that on setting up the details.  My fault mostly
for not taking the tourch that has been passed.  I am [now] offering
again, and I think we can do it.  If someone can contact me we can get this
setup ASAP.

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

Re: Kerberos 5 integration.

[David E. Cross]

I am terribly sorry.  I had 2 messages about kerboers5 come in at the same
time (one from -hackers, one from mit), I replied to to wrong one.

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

Re: FreeBSD 3.2 on a ThinkPad 360c [keyboard not working]

[David E. Cross]

 I am attempting to get FreeBSD 3.2 and/or 4.0 to go on a TP 360c.  The 
 problem I am having is that the keyboard works all the way up to sysinstall.
 I can use the keyboard in the visual kernel config/etc.  I searched and found
 under 2.2 they suggested setting flags 0x10 on syscons.  0x10 isn't documented
 to do anything uner 3/4 but I tried anyway, nothing.  I also noticed that
 flags 0x04 and 0x02 may be some use (on atkbc).  I tried 0x4, 0x2, and 0x6 to
 no avail.  help?

Here are some additional details... I tried the 2.2.8-RELEASE install with
the flags  of '0x10' on sc0.  That worked OK.  I dug through the CVS repo
and I have discovered that those are the XT keyboard options (flags 0x04
on atkbd).  so I went into the CLI config on the 3.2-STABLE bootdisk at
turned those flags on BOTH atkdb0 at atkbdc0 (just in case), still no luck.
I have looked at the source for 2.2 syscons and 3.2 atkbd and I can not see
what the difference is in the codeset initialization and keyboard translation
for the 2 types.  I would like to try 3.0-RELEASE, but I cannot find anything
that old ;)

Suggestions?

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: FreeBSD 3.2 on a ThinkPad 360c [keyboard not working]

[David E. Cross]

 You are quite right that the code in question was just moved from sc
 to atkbd and there is essentially no difference between the two
 versions.
 
 This is the first time that I hear the flag 0x10 for sc works in 2.X,
 but the flag 0x4 for atkbd does not in 3.1 or later :-(  I think
 I heard just last month that the flag works for ThinkPad 360CE...
 
 You say the keyboard works the kernel config menu and up to sysinstall,
 but it does not work in sysinstall and you cannot install the OS.
 Would you see if hitting the CAPS LOCK key changes the CAPS LED light?
 
 Kazu

I have tried all of the keys, none of them function as labeled (not even
Caps Lock).  The left shift seems to be a double-enter or similiar.

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD



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


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

FreeBSD 3.2 on a ThinkPad 360c [keyboard not working]

[David E. Cross]

I am attempting to get FreeBSD 3.2 and/or 4.0 to go on a TP 360c.  The 
problem I am having is that the keyboard works all the way up to sysinstall.
I can use the keyboard in the visual kernel config/etc.  I searched and found
under 2.2 they suggested setting flags 0x10 on syscons.  0x10 isn't documented
to do anything uner 3/4 but I tried anyway, nothing.  I also noticed that
flags 0x04 and 0x02 may be some use (on atkbc).  I tried 0x4, 0x2, and 0x6 to
no avail.  help?

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

Re: FreeBSD 3.2 on a ThinkPad 360c [keyboard not working]

[David E. Cross]

 I am attempting to get FreeBSD 3.2 and/or 4.0 to go on a TP 360c.  The 
 problem I am having is that the keyboard works all the way up to sysinstall.
 I can use the keyboard in the visual kernel config/etc.  I searched and found
 under 2.2 they suggested setting flags 0x10 on syscons.  0x10 isn't documented
 to do anything uner 3/4 but I tried anyway, nothing.  I also noticed that
 flags 0x04 and 0x02 may be some use (on atkbc).  I tried 0x4, 0x2, and 0x6 to
 no avail.  help?

Here are some additional details... I tried the 2.2.8-RELEASE install with
the flags  of '0x10' on sc0.  That worked OK.  I dug through the CVS repo
and I have discovered that those are the XT keyboard options (flags 0x04
on atkbd).  so I went into the CLI config on the 3.2-STABLE bootdisk at
turned those flags on BOTH atkdb0 at atkbdc0 (just in case), still no luck.
I have looked at the source for 2.2 syscons and 3.2 atkbd and I can not see
what the difference is in the codeset initialization and keyboard translation
for the 2 types.  I would like to try 3.0-RELEASE, but I cannot find anything
that old ;)

Suggestions?

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

Re: FreeBSD 3.2 on a ThinkPad 360c [keyboard not working]

[David E. Cross]

 You are quite right that the code in question was just moved from sc
 to atkbd and there is essentially no difference between the two
 versions.
 
 This is the first time that I hear the flag 0x10 for sc works in 2.X,
 but the flag 0x4 for atkbd does not in 3.1 or later :-(  I think
 I heard just last month that the flag works for ThinkPad 360CE...
 
 You say the keyboard works the kernel config menu and up to sysinstall,
 but it does not work in sysinstall and you cannot install the OS.
 Would you see if hitting the CAPS LOCK key changes the CAPS LED light?
 
 Kazu

I have tried all of the keys, none of them function as labeled (not even
Caps Lock).  The left shift seems to be a double-enter or similiar.

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD



To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

host byte order in networkin routines?!?

[David E. Cross]

A friend writing some portable network tunneling software ran into an
interesting thing... when you specify "IP_HDRINCL" with SOCK_RAW,  and
IPPROTO_RAW you need to construct the outgoing packet in host byte order.

This seems wonderfully inconsistent with all of the other socket based
networking interface in FreeBSD, and it is also inconsistent with other
Operating Systems.   Would it be possible to get this changed?  I can provide
diffs if need be.

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

host byte order in networkin routines?!?

[David E. Cross]

A friend writing some portable network tunneling software ran into an
interesting thing... when you specify IP_HDRINCL with SOCK_RAW,  and
IPPROTO_RAW you need to construct the outgoing packet in host byte order.

This seems wonderfully inconsistent with all of the other socket based
networking interface in FreeBSD, and it is also inconsistent with other
Operating Systems.   Would it be possible to get this changed?  I can provide
diffs if need be.

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message

Re: So, back on the topic of enabling bpf in GENERIC...

[David E. Cross]

Here is a pro vote for enabling BPF in GENERIC:

It will let us use a dhcp client in the install programs, this is of tremendous
use to many people as DHCP starts to become much more popular.  I cannot
net install a machine at home since that is on a DHCP cable modem service.

Also, if root is compromised on a system, even if you don't have bpf installed
you would be a fool to believe that they are not sniffing packets/passwords.
At the very least Mr. Pragmatic(sp?) has shown the world the power and 
flexability of KLDs... I am sure someone could write a KLD to impliment the
functionality of a packet sniffer.  Also  an attacker, once obtaining root,
could certainly trojan ftpd/sshd/telnetd/login/whatever.  I think disabling
bpf for "security reasons" is a false sense of security.

--
David Cross   | email: [EMAIL PROTECTED] 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


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

Re: So, back on the topic of enabling bpf in GENERIC...

[David E. Cross]

Here is a pro vote for enabling BPF in GENERIC:

It will let us use a dhcp client in the install programs, this is of tremendous
use to many people as DHCP starts to become much more popular.  I cannot
net install a machine at home since that is on a DHCP cable modem service.

Also, if root is compromised on a system, even if you don't have bpf installed
you would be a fool to believe that they are not sniffing packets/passwords.
At the very least Mr. Pragmatic(sp?) has shown the world the power and 
flexability of KLDs... I am sure someone could write a KLD to impliment the
functionality of a packet sniffer.  Also  an attacker, once obtaining root,
could certainly trojan ftpd/sshd/telnetd/login/whatever.  I think disabling
bpf for security reasons is a false sense of security.

--
David Cross   | email: cro...@cs.rpi.edu 
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd 
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science| Fax: 518.276.4033
I speak only for myself.  | WinNT:Linux::Linux:FreeBSD


To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message