Re: cvs commit: src/sys/kern kern_intr.c src/sys/dev/ata ata-all.c

[Ruslan Ermilov]

On Wed, Feb 19, 2003 at 10:20:12AM +1100, Bruce Evans wrote:
> On Tue, 18 Feb 2003, Ruslan Ermilov wrote:
> 
> > On Fri, Feb 14, 2003 at 05:10:40AM -0800, Alfred Perlstein wrote:
> > > alfred  2003/02/14 05:10:40 PST
> > >
> > >   Modified files:
> > > sys/kern kern_intr.c
> > > sys/dev/ata  ata-all.c
> > >   Log:
> > >   Fix crash dumps on ata and scsi.
> > >
> > [...]
> > >   To fix ata, use what appears to be a polling method if we're dumping,
> > >   I stole this from tmm but added code to ensure that this change is
> > >   only in effect while dumping.
> > >
> > >   Tested by: des
> > >
> > FWIW, if I propagate this change to the !dumping case, it also
> > fixes the ``resume stucks in "ata1: resetting devices .."'' bug
> > I was having with my ThinkPad 600X:
> >
> > %%%
> > Index: ata-all.c
> > ===
> > RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v
> > retrieving revision 1.165
> > diff -u -p -r1.165 ata-all.c
> > --- ata-all.c   14 Feb 2003 13:10:40 -  1.165
> > +++ ata-all.c   18 Feb 2003 10:08:22 -
> > @@ -486,8 +486,7 @@ ata_getparam(struct ata_device *atadev,
> >
> >  /* apparently some devices needs this repeated */
> >  do {
> > -   if (ata_command(atadev, command, 0, 0, 0,
> > -   dumping ? ATA_WAIT_READY : ATA_WAIT_INTR)) {
> > +   if (ata_command(atadev, command, 0, 0, 0, ATA_WAIT_READY)) {
> > ata_prtdev(atadev, "%s identify failed\n",
> >command == ATA_C_ATAPI_IDENTIFY ? "ATAPI" : "ATA");
> > free(ata_parm, M_ATA);
> > %%%
> 
> There is, or was, something near here that made the whole system go
> unresponsive (as seen by nfs clients) for several seconds.  I guess
> the main problem was just using polled mode in all cases here.  In
> RELENG_4, polling is done at splbio() so normally only disk devices
> are blocked, but under -current almost everything is blocked by Giant.
> 
The symptoms were as following.  The console is blocked, and if I type
something, I don't see it unless I enter into the DDB -- then what I
have typed is displayed.

> > The resume session (with apm(4)) now looks like this:
> >
> > : cbb0: PCI Memory allocated: 50103000
> > : cbb1: PCI Memory allocated: 50102000
> > : pcm0: detached
> > : csa: card is Thinkpad 600X/A20/T20
> > : pcm0:  on csa0
> > : pcm0: 
> > : wakeup from sleeping state (slept 00:00:10)
> > : ata0: resetting devices ..
> > : done
> > : ata1: resetting devices ..
> > : ata1-slave: timeout waiting for cmd=ec s=01 e=24
> > : ata1-slave: ATA identify failed
> > : done
> 
> Apparently the timeout is too short or the interrupt got lost.  The
> timeout seems to be too short.  It is 10 seconds, but IIRC the spec
> is says 30 seconds for reset of the master and a bit more for the
> slave.  Since things work with polling, we know that the device state
> changed properly.  We could test for this state change instead of
> always aborting after the timeout, and do finer grained and more sleeps
> to determine the precise timeout required.
> 
I recall seeing the ``stray irq 15'' too, so yes, that may likely
be the case here.  I will try bumping up the ATA_WAIT_INTR timeout
later today and let you know the results.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age



msg52695/pgp0.pgp
Description: PGP signature

Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...

[phk]

In message <[EMAIL PROTECTED]>, Warner Losh write
s:
>imp 2003/02/18 21:47:47 PST
>
>  Modified files:
>[... everything ...]
> uma_core.c vm_map.c vm_object.c 
>  Log:
>  Back out M_* changes, per decision of the TRB.
>  
>  Approved by: trb

The attached patch will print a backtrace if any calls to malloc
fail to have either M_WAITOK or M_NOWAIT.

Please put this patch in your tree and help fix any issues.

So far (10 minutes) my disk-less testbox has found no issues.

Poul-Henning


Index: kern/kern_malloc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.116
diff -u -r1.116 kern_malloc.c
--- kern/kern_malloc.c  19 Feb 2003 05:47:25 -  1.116
+++ kern/kern_malloc.c  19 Feb 2003 07:55:19 -
@@ -167,11 +167,21 @@
 #endif
register struct malloc_type *ksp = type;
 
+   indx = flags & (M_WAITOK | M_NOWAIT);
+   if (indx == M_NOWAIT) {
+   /* OK */
+   } else if (indx == M_WAITOK) {
+   /* OK */
+   } else {
+   printf("Missing M_WAITOK flag\n");
+   backtrace();
+   flags |= M_WAITOK;
+   }
 #if 0
if (size == 0)
Debugger("zero size malloc");
 #endif
-   if (!(flags & M_NOWAIT))
+   if (flags & M_WAITOK)
KASSERT(curthread->td_intr_nesting_level == 0,
   ("malloc(M_WAITOK) in interrupt context"));
if (size <= KMEM_ZMAX) {
Index: sys/malloc.h
===
RCS file: /home/ncvs/src/sys/sys/malloc.h,v
retrieving revision 1.70
diff -u -r1.70 malloc.h
--- sys/malloc.h19 Feb 2003 05:47:45 -  1.70
+++ sys/malloc.h19 Feb 2003 07:58:41 -
@@ -46,11 +46,11 @@
 /*
  * flags to malloc.
  */
-#defineM_WAITOK0x
 #defineM_NOWAIT0x0001  /* do not block */
-#defineM_USE_RESERVE   0x0002  /* can alloc out of reserve memory */
-#defineM_ZERO  0x0004  /* bzero the allocation */
-#defineM_NOVM  0x0008  /* don't ask VM for pages */
+#defineM_WAITOK0x0002  /* do not block */
+#defineM_ZERO  0x0100  /* bzero the allocation */
+#defineM_NOVM  0x0200  /* don't ask VM for pages */
+#defineM_USE_RESERVE   0x0400  /* can alloc out of reserve memory */
 
 #defineM_MAGIC 877983977   /* time when first defined :-) */
 

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

could sleep with "buf queue lock" in -current

[Poul-Henning Kamp]

../../../kern/kern_lock.c:239: could sleep with "buf queue lock" locked from 
../../../kern/vfs_bio.c:2143
Debugger("witness_sleep")
Stopped at  0xc0409aae = Debugger+0x7e: xchgl   %ebx,0xc05b37e0 = in_Debugger.0
db> trace
Debugger(c04530c8,c0469eb9,ef,c046e636,c0470d54) at 0xc0409aae = Debugger+0x7e
witness_sleep(1,c419ad50,c0469eb9,ef,c1501e10) at 0xc026ad3c = witness_sleep+0x21c
lockmgr(c419ae04,10001,c419ad50,c1501e10,12) at 0xc021deee = lockmgr+0xce
vop_sharedlock(d68b6c94,0,c0472bac,35c,c02233aa) at 0xc02ae440 = vop_sharedlock+0xd0
vn_lock(c419ad50,12,c1501e10,85f,c02160d5) at 0xc02cfdf0 = vn_lock+0x140
flushbufqueues(c3f637f0,0,c0470d2f,81f,64) at 0xc02a43e7 = flushbufqueues+0x1f7
buf_daemon(0,d68b6d48,c04695c0,366,0) at 0xc02a3f13 = buf_daemon+0x133
fork_exit(c02a3de0,0,d68b6d48) at 0xc0213215 = fork_exit+0x135
fork_trampoline() at 0xc040c29e = fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xd68b6d7c, ebp = 0 ---
db> 


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

reproducable kernel crash

[David Xu]

OK, I can 100% let SMP kernel crash here.
Turn on cpu hlt sysctl, 
%sysctl -w  machdep.cpu_idle_hlt=1
then copy a large file to my home directory
%cp /boot/kernel .
Press ctl+alt+del immediately after copy.
When in reboot state, kernel crashed when trying to 
shutdown bufdaemon.
backtrace shows the trap is at cpu_idle+0x1e, the fault
is page fault referencing zero address.
if I set machdep.cpu_idle_hlt to 0, I can not reproduce
the bug.

%dmesg
Copyright (c) 1992-2003 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 5.0-CURRENT #7: Wed Feb 19 22:22:27 CST 2003
[EMAIL PROTECTED]:/home/davidxu/src/sys/i386/compile/xu2
Preloaded elf kernel "/boot/kernel/kernel" at 0xc04cc000.
Preloaded elf module "/boot/kernel/vesa.ko" at 0xc04cc0a8.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04cc154.
Timecounter "i8254"  frequency 1193182 Hz
CPU: Intel Pentium III (999.67-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x68a  Stepping = 10
  
Features=0x387fbff
real memory  = 268369920 (255 MB)
avail memory = 255410176 (243 MB)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee0
 cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee0
 io0 (APIC): apic id:  2, version: 0x00178011, at 0xfec0
Pentium Pro MTRR support enabled
VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc047fca2 (122)
VESA: NVidia
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
pcibios: BIOS version 2.10
Using $PIR table, 8 entries at 0xc00fdd20
acpi0: power button is handled as a fixed feature programming model.
Timecounter "ACPI-fast"  frequency 3579545 Hz
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
acpi_cpu0:  on acpi0
acpi_cpu1:  on acpi0
acpi_button0:  on acpi0
pcib0:  port 
0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0
pci0:  on pcib0
agp0:  mem 0xf000-0xf3ff at device 
0.0 on pci0
pcib1:  at device 1.0 on pci0
pci1:  on pcib1
pci1:  at device 0.0 (no driver attached)
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0xe000-0xe00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
uhci0:  port 0xe400-0xe41f irq 5 at device 7.2 on pci0
usb0:  on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub0: port error, restarting port 1
uhub0: port error, giving up port 1
uhub0: port error, restarting port 2
uhub0: port error, giving up port 2
uhci1:  port 0xe800-0xe81f irq 5 at device 7.3 on pci0
usb1:  on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub1: port error, restarting port 1
uhub1: port error, giving up port 1
uhub1: port error, restarting port 2
uhub1: port error, giving up port 2
pci0:  at device 7.4 (no driver attached)
ed0:  port 0xec00-0xec1f irq 11 at device 9.0 on 
pci0
ed0: address 52:54:ab:52:53:8f, type NE2000 (16 bit)
fdc0:  port 0x3f7,0x3f0-0x3f5 
irq 6 drq 2 on acpi0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
ppc0 port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
atkbdc0:  port 0x64,0x60 irq 1 on acpi0
atkbd0:  flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0:  irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3
pmtimer0 on isa0
orm0:  at iomem 0xc-0xcb7ff on isa0
sc0:  on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
APIC_IO: Testing 8254 interrupt delivery
APIC_IO: routing 8254 via IOAPIC #0 intpin 2
Timecounters tick every 10.000 msec
acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0%
ad0: 57241MB  [116301/16/63] at ata0-master UDMA100
acd0: CDROM  at ata1-slave PIO4
SMP: AP CPU #1 Launched!
MBREXT Slice 5 on ad0s2:
[0] f:00 typ:7 s(CHS):5/1/65 e(CHS):255/254/255 s:63 l:20964762
[1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:20964825 l:20964825
MBREXT Slice 6 on ad0s2:
[0] f:00 typ:7 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:20964762
[1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0
Mounting root from ufs:/dev/ad0s3a

---
David Xu


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

Cardbus-attached USB controller

[Bob Bishop]

Hi,

I've got a Sitecom cardbus USB controller here, probes as:

found-> vendor=0x1033, dev=0x0035, revid=0x41
class=0c-03-10, hdrtype=0x00, mfdev=1
cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords)
lattimer=0xa8 (5040 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns)
intpin=a, irq=255
cardbus0: Resource not specified in CIS: id=10, size=1000
cardbus0:  (vendor=0x1033, dev=0x0035) at 0.0 irq 10
found-> vendor=0x1033, dev=0x0035, revid=0x41
class=0c-03-10, hdrtype=0x00, mfdev=0
cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords)
lattimer=0xa8 (5040 ns), mingnt=0x01 (250 ns), maxlat=0x2a (10500 ns)
intpin=b, irq=255
cardbus0: Resource not specified in CIS: id=10, size=1000
cardbus0:  (vendor=0x1033, dev=0x0035) at 0.1 irq 10
found-> vendor=0x1033, dev=0x00e0, revid=0x02
class=0c-03-20, hdrtype=0x00, mfdev=0
cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords)
lattimer=0xa8 (5040 ns), mingnt=0x10 (4000 ns), maxlat=0x22 (8500 ns)
intpin=c, irq=255
cardbus0: Resource not specified in CIS: id=10, size=100
cardbus0:  (vendor=0x1033, dev=0x00e0) at 0.2 irq 10

That's 2 ohci and an ehci (which I realise isn't supported (yet)).

Would someone like to give me a clue how to plumb this thing in? TIA

--
Bob Bishop		+44 (0)118 977 4017
[EMAIL PROTECTED]		fax +44 (0)118 989 4254


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

Re: background fsck deadlocks with ufs2 and big disk

[Darryl Okahata]

David Schultz <[EMAIL PROTECTED]> wrote:

> IIRC, Kirk was trying to reproduce this a little while ago in
> response to similar reports.  He would probably be interested
> in any new information.

 I don't have any useful information, but I do have a data point:

My 5.0-RELEASE system recently mysteriously panic'd, which
resulted in a partially trashed UFS1 filesystem, which caused bg
fsck to hang.

Details:

* The panic was weird, in that only the first 4-6 characters of the
  first function (in the panic stacktrace) was displayed on the console
  (sorry, forgot what it was).  Nothing else past that point was shown,
  and the console was locked up.  Ddb was compiled into the kernel, but
  ctrl-esc did nothing.

* The UFS1 filesystem in question (and I assume that it was UFS1, as I
  did not specify a filesystem type to newfs) is located on a RAID5
  vinum volume, consisting of five 80GB disks.

* Softupdates is enabled.

* When bg fsck hung (w/no disk activity), I could break into the ddb.
  Unfortunately, I don't know how to use ddb, aside from "ps".

* Disabling bg fsck allowed the system to boot.  However, fg fsck
  failed, and I had to do a manual fsck, which spewed lots of nasty
  "SOFTUPDATE INCONSISTENCY" errors.

* Disturbingly (but fortunately), I then unmounted the filesystem (in
  multi-user mode) and re-ran fsck, and fsck still found errors.  There
  should not have been any errors, as fg fsck just finished running.

  [ Unfortunately, I've forgotten what they were, and an umount/fsck
done right now shows no problems.  I think the errors were one of
the "incorrect block count" errors.  ]

* After the fsck, some files were partially truncated (& corrupted?).
  After investigating, I believe these truncated files (which were NOT
  recently modified) were in a directory in which other files were being
  created/written at the time of the panic.

-- 
Darryl Okahata
[EMAIL PROTECTED]

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.

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

Re: top-of-tree alpha kernel panics during boot

[Andrew Gallatin]

Can you post your kernel config please, along with with, if any,
CPUTYPE you have set in make.conf and a description of your machine
(mem size in particular)?  

I'm unable to reproduce the boot panic with a GENERIC as of
today. (rest of machine is from Nov 1st).  Rebuilding without
CPUTYPE now..

Drew

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

Simply impossible to format disk under current.

[David Gilbert]

I ran into an interesting problem last night ... that was very
frustrating.  I was recycling SCSI drives from some NetBSD machines
(that were client boxes) to add to a RAID server running
FreeBSD-5.0-RELEASE.

It's simply impossible to format NetBSD drives under current.

Let me expand on that.  /dev/da2 exists, but you can't say 'fdisk -I
da2' ... fdisk says that /dev/da2 doesn't exist.  /dev/da2 (and
/dev/da2c) isn't writable, so I can't blank the first few sectors.  I
even tried this in single user mode.

The problem appears to be that the FreeBSD-5.0 system sees the NetBSD
label ... so things like da2s1 don't exist.  da2a, da2b, da2c and da2g
do.  These are the NetBSD partitions.  Writing to them is verboten.  I
was hoping that da2c would allow me to blank the boot sector, but it
doesn't allow me to write.

... under FreeBSD-5.0, fdisk won't write to the disk and disklabel
won't change the NetBSD label, either.

I had to boot with my FreeBSD-4.7 recovery CD ... which would fdisk
and disklabel the disk (note that fdisking wasn't enough ... FreeBSD
still accepted the NetBSD label over the fdisk data) just fine.

... although I then ran into the issue that disklabel -e had
/mnt2/stand/vi hardcoded into it ... which is wrong.

Dave.

-- 

|David Gilbert, Velocet Communications.   | Two things can only be |
|Mail:   [EMAIL PROTECTED] |  equal if and only if they |
|http://daveg.ca  |   are precisely opposite.  |
=GLO

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

Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...

[Peter Wemm]

[EMAIL PROTECTED] wrote:

> The attached patch will print a backtrace if any calls to malloc
> fail to have either M_WAITOK or M_NOWAIT.

Please do not commit this as-is..  There is a DoS here if a user figures
out how to provoke this.  This is exactly the situation that Alfred was
worried about.

> + indx = flags & (M_WAITOK | M_NOWAIT);
> + if (indx == M_NOWAIT) {
> + /* OK */
> + } else if (indx == M_WAITOK) {
> + /* OK */
> + } else {
> + printf("Missing M_WAITOK flag\n");
> + backtrace();
> + flags |= M_WAITOK;
> + }

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5


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

Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S

[Matthew Dillon]

4.x and -current use the same mechanism, except 4.x uses MFS and
-current uses MD.

Ignore the handbook.  Try 'man diskless'.

kenv is only used in current's rc.diskless scripts, and it 
resides in /bin on -current.  kenv is not used in 4.x's
diskless scripts.

Basically what you do is create a files and directories in
/conf/base and /conf/default which are used to populate the
MFS/MD root and other directories.  I have included my setup
at the end.


:I was running a VIA Mini-ITX diskless box off a 4.7-STABLE box for a
:while using a root fs created by the clone_root discussed in the
:handbook, then some tweaks.  I'm having a heck of a time trying to get
:this running under 5.0-RELEASE, now sync'd to 5.0-CURRENT as of
:yesterday, then mergemastered.
:
:If someone can provide some clues or pointers, I'd be happy to doc how
:I get it to work (for the Handbook?) and could take a stab at updating
:clone_root for 5.x if it's needed.
:
:
:Background:
:
:Been using FreeBSD since 2.2.x.  I can code. I can RTFM. :-)
:
:I've read the 5.0 Release Notes and Early Adopters docs.
:...
:
:Upon boot, after kernel loaded, console shows a bunch of rc.conf-style
:vars being set, then spews some debugging which I put in
:$DISKLESSROOT/conf/default/etc/rc.d/diskless, so it's running that
:rather than the old /etc/rc.diskless* files. I've moved the "mount -a"
:near the top of rc.d/diskless since it runs commands which are and not
:available until /usr is mounted (e.g., mtree).  The NFS mount fails
:with a message I don't understand:
:
:Can someone point me in the right direction ?  Thanks!

I'm not sure what you are doing here.  You don't want to override
any rc.d files in /conf.  That will blow things up for sure.

Ok, here is an ls -lR of my setup:

# ls -lR /conf
total 2
drwxr-xr-x  5 root  wheel  512 Dec 21 10:37 base
drwxr-xr-x  3 root  wheel  512 Dec 19 21:56 default

/conf/base:
total 5
drwxr-xr-x  2 root  wheel  512 Dec 21 10:37 dev
drwxr-xr-x  2 root  wheel  512 Dec 19 22:22 etc
-rw-r--r--  1 root  wheel   11 Dec 20 15:38 etc.remove
drwxr-xr-x  2 root  wheel  512 Dec 20 14:31 root
-rw-r--r--  1 root  wheel   12 Dec 20 15:38 root.remove

/conf/base/dev:
total 2
-rw-r--r--  1 root  wheel  18 Dec 21 10:37 diskless_remount
-rw-r--r--  1 root  wheel   6 Dec 19 22:22 md_size

/conf/base/etc:
total 2
-rw-r--r--  1 root  wheel  18 Dec 19 22:10 diskless_remount
-rw-r--r--  1 root  wheel   6 Dec 19 22:22 md_size

/conf/base/root:
total 2
-rw-r--r--  1 root  wheel  19 Dec 20 14:31 diskless_remount
-rw-r--r--  1 root  wheel   5 Dec 20 14:31 md_size

/conf/default:
total 1
drwxr-xr-x  3 root  wheel  512 Dec 20 11:18 etc

/conf/default/etc:
total 4
-rw-r--r--   1 root  wheel   184 Feb 18 18:16 fstab
-rw-r--r--   1 root  wheel   867 Dec 21 00:04 rc.conf
-rw-r--r--   1 root  wheel   197 Feb 18 18:19 rc.local

And some cats:

apollo:/conf# cat /conf/base/dev/diskless_remount
216.240.41.2:/dev
apollo:/conf# cat /conf/base/dev/md_size
16384

apollo:/conf# cat /conf/base/etc/diskless_remount 
216.240.41.2:/etc
apollo:/conf# cat /conf/base/etc/md_size
16384

apollo:/conf# cat /conf/base/root/diskless_remount 
216.240.41.2:/root
apollo:/conf# cat /conf/base/root/md_size
8192

apollo:/conf# cat /conf/default/etc/rc.conf
hostname="mobile.backplane.com"

nfs_client_enable="YES"
local_startup=""

ip_portrange_first=4000
ip_portrange_last=8192
syslogd_enable="NO"

firewall_enable="YES"
firewall_type="/etc/ipfw.conf"

ntpdate_enable="YES"
ntpdate_flags="apollo.backplane.com"
xntpd_enable="YES"

sshd_enable="YES"
sendmail_enable="NO"
linux_enable="NO"

apollo:/conf# cat /conf/default/etc/fstab
# DeviceMountpoint  FStype  Options DumpPass#
apollo:/usr /usrnfs ro  0   0
apollo:/FreeBSD /FreeBSDnfs ro  0   0
apollo:/backup1 /usr/objnfs rw  0   0
proc/proc   procfs  rw  0   0


That's basically it.  You can also use /conf/base/.remove and
/conf/default/.remove files to list files to remove from the
clone.  You don't have to specify a network config in your 
/conf/default/etc/rc.conf because the network will have already
been setup.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


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

Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S

[Matthew Dillon]

I'm not sure what is occuring here but it sounds like 
cockpit trouble somewhere.  Make sure your NFS server is
exporting to your subnet and that it is running the
necessary services, (portmap, mountd, nfsd -t -u -n 4).
If you have another box that you can boot normally
(not netboot), test the NFS server from that box by
mounting / and /usr:

other# mount 192.168.255.185:/usr /mnt

Or, if you have no other box, make sure you can mount
the server onto the server itself as a test:

nfsserver# mount localhost:/usr /mnt
nfsserver# mount myaddress:/usr /mnt(aka 192.168.255.185)

If you are running a firewire on the server, make sure
it is letting NFS through to your LAN.

It is also possible that someone has broken something in NFS
recently.  The -current I am running (which works fine as
a server for my EPIA 5000 and EPIA M 9000) is several weeks 
old.

If your /usr partition is on / on your server (i.e. not 
its own partition), then remember to use the -alldirs option
in /etc/exports for / and /usr.  If /usr is on its own
partition you don't need -alldirs unless you are trying to
mount a subdirectory in / or /usr.  You *might* need -alldirs
on your / export.  In anycase, I always set -alldirs on all
my read-only exports and that is what I would recommend you
do too.

-Matt

:Chris Shenton <[EMAIL PROTECTED]> writes:
:
:> I've moved the "mount -a" near the top of rc.d/diskless since it
:> runs commands which are and not available until /usr is mounted
:> (e.g., mtree).  The NFS mount fails with a message I don't
:> understand:
:> 
:>   [udp] pectopah.shenton.org:/usr: RPCPROG_NFS: RPC: Unknown host
:
:Tasteless self-followup:
:
:I get the same error when the boot process fails and drops me to a
:shell; I can get it with UDP or TCP mounts. For example:
:
:  mount_nfs -U -2 192.168.255.185:/usr /mnt
:  mount_nfs -U -3 192.168.255.185:/usr /mnt
:  mount_nfs -T -2 192.168.255.185:/usr /mnt
:  mount_nfs -T -3 192.168.255.185:/usr /mnt
:
:The only difference is the [udp] vs [tcp] in the error msg:
:
:  [tcp] 192.168.255.185:/usr: RPCPROG_NFS: RPC: Unknown host
:
:I sniffed traffic with tcpdump and ethereal: the diskless client is
:contacting the server so it's not having problems resolving that IP
:addr.
:...

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

Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S

[Chris Shenton]

Matthew Dillon <[EMAIL PROTECTED]> writes:

> 4.x and -current use the same mechanism, except 4.x uses MFS and
> -current uses MD.

4.x uses /etc/diskless[12] while 5.x (by default) uses
/etc/rc.d/(init)?diskless.  The latter is works very differently than
the former.


> Ignore the handbook.  Try 'man diskless'.

Ouch, will try the man.



> kenv is only used in current's rc.diskless scripts, and it 
> resides in /bin on -current.  

Not on mine:

  chris@Pectopah<103> whereis kenv
  kenv: /usr/bin/kenv /usr/share/man/man1/kenv.1.gz /usr/src/bin/kenv
  chris@Pectopah<104> ls /bin/kenv
  ls: /bin/kenv: No such file or directory
  chris@Pectopah<105> uname -a
  FreeBSD Pectopah.shenton.org 5.0-RELEASE-p1 FreeBSD 5.0-RELEASE-p1 #0: Sun Feb 16 
16:10:36 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/Pectopah  i386

And the /usr/bin/kenv needs the elf libraries to run, it's not static,
so shouldn't live in /sbin and can't run on a diskless box until /usr
is mounted.

> Basically what you do is create a files and directories in
> /conf/base and /conf/default which are used to populate the
> MFS/MD root and other directories.  I have included my setup
> at the end.

Which startup scripts are you running, old diskless[12] or new
rc.d/(init)?diskless ?

Thanks for your examples, I'll plow through them tonight. But -- more
below -- these sure look like 4.x-compatible stuff, not 5.0.

> /conf/base:
> total 5
> drwxr-xr-x  2 root  wheel  512 Dec 21 10:37 dev
> drwxr-xr-x  2 root  wheel  512 Dec 19 22:22 etc
> -rw-r--r--  1 root  wheel   11 Dec 20 15:38 etc.remove
> drwxr-xr-x  2 root  wheel  512 Dec 20 14:31 root
> -rw-r--r--  1 root  wheel   12 Dec 20 15:38 root.remove
> 
> /conf/base/dev:
> total 2
> -rw-r--r--  1 root  wheel  18 Dec 21 10:37 diskless_remount
> -rw-r--r--  1 root  wheel   6 Dec 19 22:22 md_size

The etc.remove and md_size are used by 4.x's diskless[12] but NOT by
the 5.x /etc/rc.d/(init?)diskless scripts.  Are you using the old
startup rc stuff, possibly changing the default value in
/etc/defaults/rc.conf:

  rc_ng="YES"   # Set to NO to disable new-style rc scripts.

If so and it works for you, I can certainly do the same.  But I'd
still like to figure how to get the 5.x rc.d/* scripts to do their
thing.

Actually, I don't see any code to look for that md_size or
diskless_remount in either of 5.0's rc.diskless[12] or
rc.d/(init)?diskless.  I do know that what you're describing is in
4.x's rc.diskless[12], and I did have that working on a 4.7S system.
That's why I'm having so much trouble with the 5.0 diskless boot --
everything's changed.

Lemme know if I'm way off base but it sounds like you're describing a
4.x diskless boot and my problem's with 5.0.

Thanks a bunch!

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

Re: UFS/SOFTUPDATE inconsistency

[Pascal Giannakakis]

Paolo Pisati schrieb:

[root@southcross root]# fsck /dev/ad0s1e
** /dev/ad0s1e (NO WRITE)
** Last Mounted on /usr
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
MISSING '.'  I=667872  OWNER=root MODE=40755
SIZE=512 MTIME=Feb 10 16:54 2003
DIR=/ports/cad/gwave

UNEXPECTED SOFT UPDATE INCONSISTENCY
CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS files

UNEXPECTED SOFT UPDATE INCONSISTENCY
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? no

SUMMARY INFORMATION BAD
SALVAGE? no

BLK(S) MISSING IN BIT MAPS
SALVAGE? no

209599 files, 1970937 used, 2594963 free (52235 frags, 317841 blocks, 1.1% fragm
entation)
[root@southcross root]#

any on how to fix it?



Best way: boot with CD 2 of FreeBSD 5.0 and go to Fixit -> CD-ROM. Then 
in console (ALT + F4) run:

fsck -y /dev/ad0s1e

You can also try "boot -s" at boot prompt and then run fsck.


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

Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...

[phk]

In message <[EMAIL PROTECTED]>, Peter Wemm writes:
>[EMAIL PROTECTED] wrote:
>
>> The attached patch will print a backtrace if any calls to malloc
>> fail to have either M_WAITOK or M_NOWAIT.
>
>Please do not commit this as-is..  There is a DoS here if a user figures
>out how to provoke this.  This is exactly the situation that Alfred was
>worried about.

I have no intention of committing this.

The email from the TRB@ indicated that a plan exists, this patch was
merely meant as an aid to people to find any issues up front.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S

[Matthew Dillon]

:Matthew Dillon <[EMAIL PROTECTED]> writes:
:
:> 4.x and -current use the same mechanism, except 4.x uses MFS and
:> -current uses MD.
:
:4.x uses /etc/diskless[12] while 5.x (by default) uses
:/etc/rc.d/(init)?diskless.  The latter is works very differently than
:the former.

4.x uses /etc/rc.diskless[12].  I synchronized most of -current and
-stable's rc.diskless scripts a month or two ago so even though parts
of the scripts are different (like the use of MFS instead of MD),
they should operate according to the same /conf rules.

:> kenv is only used in current's rc.diskless scripts, and it 
:> resides in /bin on -current.  
:
:Not on mine:
:
:  chris@Pectopah<103> whereis kenv
:  kenv: /usr/bin/kenv /usr/share/man/man1/kenv.1.gz /usr/src/bin/kenv
:  chris@Pectopah<104> ls /bin/kenv
:  ls: /bin/kenv: No such file or directory

Are you sure you have done a recent buildworld/installworld?  It
sounds like you haven't.  In -current kenv is in /bin  (i.e.
the source is in /usr/src/bin/kenv on -current) as of the 15th of
this month.  But it still should have worked because /usr should
have been mounted by then.

:> Basically what you do is create a files and directories in
:> /conf/base and /conf/default which are used to populate the
:> MFS/MD root and other directories.  I have included my setup
:> at the end.
:
:Which startup scripts are you running, old diskless[12] or new
:rc.d/(init)?diskless ?

Both should work the same.  The new rc.d/initdiskless and rc.d/diskless
run the same rules that rc.diskless1  and rc.diskless2 do.

:Thanks for your examples, I'll plow through them tonight. But -- more
:below -- these sure look like 4.x-compatible stuff, not 5.0.

4.x and 5.x work the same.  That is, -stable and -current work the same.
If you are running an older 4.x (possibly even the last 4.x release)
it may not have the new scripts.


:Actually, I don't see any code to look for that md_size or
:diskless_remount in either of 5.0's rc.diskless[12] or
:rc.d/(init)?diskless.  I do know that what you're describing is in
:4.x's rc.diskless[12], and I did have that working on a 4.7S system.
:That's why I'm having so much trouble with the 5.0 diskless boot --
:everything's changed.
:..
:Thanks a bunch!

You must be working off an out of date source tree.

I have included -current's current /usr/src/etc/rc.d/initdiskless script
below for you to compare against your sources.  If your sources are out
of date you should update them (e.g. via cvsup or whatever you use to
get the sources).  As you can see, the initidiskless script is full
of references to md_size :-)

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


#!/bin/sh
#
# Copyright (c) 1999  Matt Dillion
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
# $FreeBSD: src/etc/rc.d/initdiskless,v 1.23 2003/02/15 16:29:20 jhay Exp $
#
# PROVIDE: initdiskless
# KEYWORD: FreeBSD

 
# On entry to this script the entire system consists of a read-only root
# mounted via NFS.  We use the contents of /conf to create and populate
# memory filesystems.  The kernel has run BOOTP and configured an interface
# (otherwise it would not have been able to mount the NFS root!)
#
# The following directories are scanned.  Each sucessive directory overrides
# (is merged into) the previous one.
#
#   /conf/base  universal base
#   /conf/default   modified by a secondary universal base
#   /conf/${ipba}   modified based on the assigned broadcast IP
#   /conf/${ip} modified based on the machine's 

Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S

[Chris Shenton]

Matthew Dillon <[EMAIL PROTECTED]> writes:

> Make sure your NFS server is exporting to your subnet and that
> it is running the necessary services, (portmap, mountd, nfsd -t
> -u -n 4). 

My boot server is 5.0, so that's the kernel my diskless box gets.  My
other boxes are 4.x boxes but I'll try.   

4.x's portmap is now 5.x's rpcbind; other processes seem fine too:

   41  ??  IL 0:00.00  (nfsiod 0)
   42  ??  IL 0:00.00  (nfsiod 1)
   43  ??  IL 0:00.00  (nfsiod 2)
   44  ??  IL 0:00.00  (nfsiod 3)
  276  ??  Ss 0:00.08 /usr/sbin/rpcbind
  339  ??  Is 0:00.08 /usr/sbin/mountd -r
  345  ??  Is 0:00.02 nfsd: master (nfsd)
  347  ??  I  2:03.22 nfsd: server (nfsd)
  348  ??  I  0:12.20 nfsd: server (nfsd)
  349  ??  I  0:06.56 nfsd: server (nfsd)
  350  ??  I  0:02.03 nfsd: server (nfsd)

> If you have another box that you can boot normally (not netboot),
> test the NFS server from that box by mounting / and /usr:
> 
> other# mount 192.168.255.185:/usr /mnt


I believe I tried mounting a 4.x volume onto the diskless 5.0 box and
it failed in the same way.  I didn't take careful notes so I'll
repeat.

I can mount the 5.0 boot server's /usr onto a 4.7S client with no
problem:

  thanatos(4.7S)# mount 192.168.255.185:/usr /mnt
  thanatos(4.7S)# mount
  /dev/da0s1a on / (ufs, local)
  /dev/da0s1e on /tmp (ufs, local)
  /dev/da0s1g on /usr (ufs, NFS exported, local)
  /dev/da0s1d on /usr/local (ufs, NFS exported, local)
  /dev/da0s1f on /var (ufs, local)
  procfs on /proc (procfs, local)
  linprocfs on /usr/compat/linux/proc (linprocfs, local)
  /dev/da0s1h on /home.THANATOS (ufs, local)
  pectopah:/home on /home (nfs)
  pectopah:/usr/local on /usr/localnew (nfs)
  pectopah:/usr/X11R6 on /usr/local/X11R6 (nfs)
  192.168.255.185:/usr on /mnt (nfs)

The name pectopah is the addr 192.168.255.185 and is the 5.0 NFS
server.

So, it seems it's something broken on my 5.0 NFS client's side.  But I
can mount a 4.7S-exported filesystem onto my 5.0 boot-server so at
least its mount_nfs is OK:

  /sbin/mount_nfs 192.168.255.180:/usr /mnt


> It is also possible that someone has broken something in NFS
> recently.  The -current I am running (which works fine as
> a server for my EPIA 5000 and EPIA M 9000) is several weeks 
> old.

Hmmm, how could I check this out? I'm happy to do testing and provide
feedback. 

> If your /usr partition is on / on your server (i.e. not 
> its own partition), then remember to use the -alldirs option
> in /etc/exports for / and /usr.  If /usr is on its own
> partition you don't need -alldirs unless you are trying to
> mount a subdirectory in / or /usr.  You *might* need -alldirs
> on your / export.  In anycase, I always set -alldirs on all
> my read-only exports and that is what I would recommend you
> do too.

I've removed the readonly flags until I get this working.  I have
separate / and /usr partitions; here's my 5.0 boot-server's
/etc/exports file (Kitchen is the diskless box :-)

  /usr/local  -alldirs -maproot=root  Sisyphus Thanatos Beatnik Kitchen
  /usr-alldirs -maproot=root  Sisyphus Thanatos Beatnik Kitchen
  /home-maproot=root  Sisyphus Thanatos Beatnik Kitchen

And the dhcpd.conf which told the diskless client where to get it's
"/" partition from (and that is successful):

host Kitchen.shenton.org {
hardware ethernet   00:40:63:c3:89:bb;
fixed-address   kitchen.shenton.org;
filename"pxeboot";
option root-path"192.168.255.185:/usr/local/diskless";
}

Am I correct that I only need to have "mount_nfs" on the diskless
client, that I do NOT need an rpcbind running on the diskless client
before issuing the mount? Since pxeboot (?) mounts / via NFS, I'm not
understanding why mount_nfs can't. 

Thanks again.

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

Page fault on disk-less machine

[Poul-Henning Kamp]

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x34
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc018fd20
stack pointer   = 0x10:0xc5fd27a4
frame pointer   = 0x10:0xc5fd27c0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 414 (cron)
kernel: type 12 trap, code=0
Stopped at  0xc018fd20 = _mtx_lock_flags+0x40:  cmpl$0xc02c1160,0(%ecx)
db> trace
_mtx_lock_flags(34,0,c02a5f56,9e,c0d9e1e0) at 0xc018fd20 = _mtx_lock_flags+0x40
namei(c5fd29b8,c5fd2c34,c044,c0570d00,c0d9e1e0) at 0xc01de06d = namei+0x16d
vn_open_cred(c5fd29b8,c5fd2980,0,c0554e00,c02167cf) at 0xc01efce8 = vn_open_cred+0x258
nfs_dolock(c5fd2b98,758,c0e066a8,c0db3e10,c0e066a8) at 0xc02230f5 = nfs_dolock+0x2c5
nfs_advlock(c5fd2b98,0,c029ee60,761,c02b6800) at 0xc0222578 = nfs_advlock+0x58
fdrop_locked(c0db3e10,c0d9e1e0,c029ee60,69e,6002) at 0xc017fa28 = fdrop_locked+0x138
fdrop(c0db3e10,c0d9e1e0,c018fe06,c03b3e58,6002) at 0xc017f50e = fdrop+0x3e
closef(c0db3e10,c0d9e1e0,c029ee60,595,0) at 0xc017f4bc = closef+0x12c
fdfree(c0d9e1e0,0,c029f2f4,f2,1) at 0xc017ed46 = fdfree+0x116
exit1(c0d9e1e0,100,c029f2f4,73,c5fd2d40) at 0xc0184bc7 = exit1+0x3b7
sys_exit(c0d9e1e0,c5fd2d10,c02b0451,407,1) at 0xc0184801 = sys_exit+0x41
syscall(2f,2f,2f,0,) at 0xc027dc07 = syscall+0x257
Xint0x80_syscall() at 0xc026dabd = Xint0x80_syscall+0x1d
--- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280c36bf, esp = 0xbfbffbec, ebp = 
0xbfbffc08 ---
db>

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S

[Chris Shenton]

Matthew Dillon <[EMAIL PROTECTED]> writes:

> Are you sure you have done a recent buildworld/installworld?  It
> sounds like you haven't.  In -current kenv is in /bin  (i.e.
> the source is in /usr/src/bin/kenv on -current) as of the 15th of
> this month.

Well, I'll be danged. I installed 5.0R on Saturday via FTP from
ftp*.freebsd.org, did a "cvsup ... /usr/share/examples/cvsup/standard-supfile"
then make world.  But I see it in /usr/src/bin/kenv now, cvsupped last
night.  Rebuilding now.  Then need to redo clone_root to populate my
diskless root hierarchy.

Thanks for the kick in the butt.

> You must be working off an out of date source tree.

Weird, perhaps I fat fingered and cvsupped "stable" and built that --
installing onto a Current system.  That would explain a lot of this
ugliness. 


> I have included -current's current /usr/src/etc/rc.d/initdiskless script

Thank you. 

> If your sources are out of date you should update them...  As
> you can see, the initidiskless script is full of references to
> md_size :-)
> 
> # Copyright (c) 1999  Matt Dillion

Ah hah... :-)

> # $FreeBSD: src/etc/rc.d/initdiskless,v 1.23 2003/02/15 16:29:20 jhay Exp $

OK, this is weird; I cvsup daily but am two versions behind you:


  Pectopah# cvsup -l 1 -g -h cvsup2.freebsd.org 
/usr/share/examples/cvsup/standard-supfile 
  Connected to cvsup2.freebsd.org
  Updating collection src-all/cvs
  Finished successfully

  Pectopah# grep '$FreeBSD' /usr/src/etc/rc.d/initdiskless 
  # $FreeBSD: src/etc/rc.d/initdiskless,v 1.21 2002/10/12 10:31:31 schweikh Exp $

Being out of sync would explain a lot.  Looks like the tag in
  "standard-supfile" points to the wrong thing, rather than the source
  for CURRENT:

  # $FreeBSD: src/share/examples/cvsup/standard-supfile,v 1.21.2.1 2003/01/16 05:59:14 
scottl Exp $
  #
  # This file contains all of the "CVSup collections" that make up the
  # FreeBSD-current source tree.
  ...
  *default release=cvs tag=RELENG_5_0

OK, I'll change this to "tag=." and recvsup, try again.  A big "doh!"

Many thanks.


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

Re: Diskless: 5.0R scripts, boot, NFS mount problems I didn't have in 4.7S

[Matthew Dillon]

:OK, I'll change this to "tag=." and recvsup, try again.  A big "doh!"
:
:Many thanks.

Yup, the 5.0 release tag was messing up your cvsup.

Keep at it!  Once you get the diskless stuff working with the more recent
sources it will become a whole lot easier to maintain it.  For one thing,
you won't have to maintain a complete copy of /etc any more :-), just
overrides for particular files.

I'm not sure what is going on with your NFS issues, but hopefully you
will be able to solve it with a fully updated system.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>

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

Re: background fsck deadlocks with ufs2 and big disk

[Brad Knowles]

At 9:15 AM -0800 2003/02/19, Darryl Okahata wrote:


 * The UFS1 filesystem in question (and I assume that it was UFS1, as I
   did not specify a filesystem type to newfs) is located on a RAID5
   vinum volume, consisting of five 80GB disks.

 * Softupdates is enabled.


	You know, vinum & softupdates have had bad interactions with each 
other for as long as I can remember.  Has this truly been a 
consistent thing (as I seem to recall), or has this been an 
on-again/off-again situation?

--
Brad Knowles, <[EMAIL PROTECTED]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++)

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

Re: Page fault on disk-less machine

[Lars Eggert]

Poul-Henning Kamp wrote:

Fatal trap 12: page fault while in kernel mode


FWIW, Craig Boston and me see the same panics (threads on -current: 
"panic starting gnome" and "VFS panic (possibly NFS-locking related?)").

fault virtual address   = 0x34
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc018fd20
stack pointer   = 0x10:0xc5fd27a4
frame pointer   = 0x10:0xc5fd27c0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 414 (cron)
kernel: type 12 trap, code=0
Stopped at  0xc018fd20 = _mtx_lock_flags+0x40:  cmpl$0xc02c1160,0(%ecx)
db> trace
_mtx_lock_flags(34,0,c02a5f56,9e,c0d9e1e0) at 0xc018fd20 = _mtx_lock_flags+0x40
namei(c5fd29b8,c5fd2c34,c044,c0570d00,c0d9e1e0) at 0xc01de06d = namei+0x16d
vn_open_cred(c5fd29b8,c5fd2980,0,c0554e00,c02167cf) at 0xc01efce8 = vn_open_cred+0x258
nfs_dolock(c5fd2b98,758,c0e066a8,c0db3e10,c0e066a8) at 0xc02230f5 = nfs_dolock+0x2c5
nfs_advlock(c5fd2b98,0,c029ee60,761,c02b6800) at 0xc0222578 = nfs_advlock+0x58
fdrop_locked(c0db3e10,c0d9e1e0,c029ee60,69e,6002) at 0xc017fa28 = fdrop_locked+0x138
fdrop(c0db3e10,c0d9e1e0,c018fe06,c03b3e58,6002) at 0xc017f50e = fdrop+0x3e
closef(c0db3e10,c0d9e1e0,c029ee60,595,0) at 0xc017f4bc = closef+0x12c
fdfree(c0d9e1e0,0,c029f2f4,f2,1) at 0xc017ed46 = fdfree+0x116
exit1(c0d9e1e0,100,c029f2f4,73,c5fd2d40) at 0xc0184bc7 = exit1+0x3b7
sys_exit(c0d9e1e0,c5fd2d10,c02b0451,407,1) at 0xc0184801 = sys_exit+0x41
syscall(2f,2f,2f,0,) at 0xc027dc07 = syscall+0x257
Xint0x80_syscall() at 0xc026dabd = Xint0x80_syscall+0x1d
--- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x280c36bf, esp = 0xbfbffbec, ebp = 0xbfbffc08 ---
db>



Lars
--
Lars Eggert <[EMAIL PROTECTED]>   USC Information Sciences Institute



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Page fault on disk-less machine

[Craig Boston]

On Wed, 2003-02-19 at 15:12, Lars Eggert wrote:
> Poul-Henning Kamp wrote:
> > Fatal trap 12: page fault while in kernel mode
> 
> FWIW, Craig Boston and me see the same panics (threads on -current: 
> "panic starting gnome" and "VFS panic (possibly NFS-locking related?)").

When I get home tonight I'll try staticly compiling in the NFS client
code and see if I can get a better crash dump to work with.

I'm not too familiar with this part of the source tree, so no guarantees
about my debugging skills ;)

Craig


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

Re: cvs commit: src/sys/alpha/alpha busdma_machdep.c src/sys/alpha/osf1 imgact_osf1.c osf1_misc.c src/sys/cam cam_periph.c cam_sim.c cam_xpt.c src/sys/cam/scsi scsi_cd.c scsi_ch.c scsi_da.c scsi_low.c scsi_sa.c scsi_target.c src/sys/coda cnode.h ...

[Giorgos Keramidas]

On 2003-02-19 09:14, [EMAIL PROTECTED] wrote:
> The attached patch will print a backtrace if any calls to malloc
> fail to have either M_WAITOK or M_NOWAIT. [...]

> --- kern/kern_malloc.c19 Feb 2003 05:47:25 -  1.116
> +++ kern/kern_malloc.c19 Feb 2003 07:55:19 -
> @@ -167,11 +167,21 @@
>  #endif
>   register struct malloc_type *ksp = type;
>
> + indx = flags & (M_WAITOK | M_NOWAIT);
> + if (indx == M_NOWAIT) {
> + /* OK */
> + } else if (indx == M_WAITOK) {
> + /* OK */
> + } else {

Or, a simpler version:

/* Either M_NOWAIT or M_WAITOK must be set. */
if (indx != M_NOWAIT && indx != M_WAITOK) {
printf("Missing M_WAITOK flag\n");
backtrace();
flags |= M_WAITOK;
}

:=)


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

5.0R - panic: bwrite: buffer is not busy

[Patric Mrawek]

I am seeing a reproducible panic with

FreeBSD talisker 5.0-RELEASE FreeBSD 5.0-RELEASE #5: Wed Jan 29 10:49:32 CET 2003
root@talisker:/usr/src/sys/i386/compile/TALISKER i386

What I've done is:
- kldload uvisor.ko
- running »/usr/sbin/usbd -d -v«
- running »jpilot-sync -d -l -p /dev/ucom0«
- hitting the sync-button from my visor several times

After hitting the sync-button 5 to 10 times my box panics.

I've some coredumps handy, so I can dig (with some help) deeper into
this.

Script started on Wed Feb 19 22:16:30 2003
patric@talisker:/home/patric$ gdb -k /sys/i386/compile/TALISKER/kernel.debug 
/var/crash/vmcore.1
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x32
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc020c793
stack pointer   = 0x10:0xd8db7ad8
frame pointer   = 0x10:0xd8db7b0c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 68897 (jpilot-sync)
trap number = 12
panic: page fault

syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 11h14m26s
Dumping 511 MB
ata0: resetting devices ..
done
[CTRL-C to abort]  16[CTRL-C to abort]  32 48 64 80 96 112 128 144 160 176 192 208 224 
240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496
---
#0  doadump () at ../../../kern/kern_shutdown.c:232
232 dumping++;
(kgdb) bt
#0  doadump () at ../../../kern/kern_shutdown.c:232
#1  0xc024abd9 in boot (howto=260) at ../../../kern/kern_shutdown.c:364
#2  0xc024ae23 in panic () at ../../../kern/kern_shutdown.c:517
#3  0xc0290bd2 in bwrite (bp=0xce6aa2f0) at ../../../kern/vfs_bio.c:796
#4  0xc02922b5 in vfs_bio_awrite (bp=0xce6aa2f0) at ../../../kern/vfs_bio.c:1643
#5  0xc03183ba in ffs_fsync (ap=0xd8db78e0) at ../../../ufs/ffs/ffs_vnops.c:258
#6  0xc0317517 in ffs_sync (mp=0xc4206200, waitfor=2, cred=0xc1541e80, td=0xc03f6ee0) 
at vnode_if.h:612
#7  0xc02a5e2b in sync (td=0xc03f6ee0, uap=0x0) at ../../../kern/vfs_syscalls.c:138
#8  0xc024a7bc in boot (howto=256) at ../../../kern/kern_shutdown.c:273
#9  0xc024ae23 in panic () at ../../../kern/kern_shutdown.c:517
#10 0xc03717a2 in trap_fatal (frame=0xd8db7a98, eva=0) at ../../../i386/i386/trap.c:844
#11 0xc0371482 in trap_pfault (frame=0xd8db7a98, usermode=0, eva=50) at 
../../../i386/i386/trap.c:758
#12 0xc0370f70 in trap (frame=
  {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -656704716, tf_esi = -2144570347, 
tf_ebp = -656704756, tf_isp = -656704828, tf_ebx = -994069960, tf_edx = -656704716, 
tf_ecx = 21, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071593581, tf_cs = 8, 
tf_eflags = 66050, tf_esp = -997247744, tf_ss = -2144570347}) at 
../../../i386/i386/trap.c:445
#13 0xc0361778 in calltrap () at {standard input}:98
#14 0xc020c058 in spec_vnoperate (ap=0x0) at ../../../fs/specfs/spec_vnops.c:126
#15 0xc02ae671 in vn_ioctl (fp=0xc4244bf4, com=2150396949, data=0xd8db7c48, 
active_cred=0xd8db7b34, td=0xc4264b60)
at vnode_if.h:488
#16 0xc026f8b3 in ioctl (td=0xc4264b60, uap=0xd8db7d10) at file.h:227
#17 0xc0371aca in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 24, tf_esi = 134691616, tf_ebp = 
-1077944152, tf_isp = -656704140, tf_ebx = 1213062036, tf_edx = 24, tf_ecx = 24, 
tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 1212593395, tf_cs = 31, tf_eflags = 
582, tf_esp = -1077944244, tf_ss = 47}) at ../../../i386/i386/trap.c:1033
#18 0xc03617cd in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---

(kgdb) l *0xc020c793
0xc020c793 is in spec_ioctl (../../../fs/specfs/spec_vnops.c:346).
341 int error;
342 struct cdevsw *dsw;
343 
344 dev = ap->a_vp->v_rdev;
345 dsw = devsw(dev);
346 if (dsw->d_flags & D_NOGIANT) {
347 DROP_GIANT();
348 error = dsw->d_ioctl(dev, ap->a_command,
349 ap->a_data, ap->a_fflag, ap->a_td);
350 PICKUP_GIANT();
(kgdb)

$FreeBSD: src/sys/fs/specfs/spec_vnops.c,v 1.186 2002/11/04 07:29:20 mckusick Exp $

Patric
-- 
The problem with troubleshooting is that trouble shoots back.


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

Re: panic starting gnome

[Lars Eggert]

Terry Lambert wrote:

Debug:

>
[excellent kernel-debugging recipe snipped]

Here's a backtrace of a crashdump that should be more helpful:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 
fault virtual address   = 0x34
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc01b28c6
stack pointer   = 0x10:0xeb3b17c0
frame pointer   = 0x10:0xeb3b17e0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2104 (gconf-sanity-check-)
panic: from debugger
cpuid = 0; lapic.id = 


Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 0; lapic.id = 
instruction pointer = 0x8:0xc03019ea
stack pointer   = 0x10:0xeb3b1534
frame pointer   = 0x10:0xeb3b1540
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 2104 (gconf-sanity-check-)
panic: from debugger
cpuid = 0; lapic.id = 
boot() called on cpu#0
Uptime: 4m49s
Dumping 1023 MB
 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 
896 912 928 944 960 976 992 1008
---
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumpsys(&dumper);

(kgdb) bt
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc01bc00e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371
#2  0xc01bc627 in panic (fmt=0xc0349b8d "from debugger")
at /usr/src/sys/kern/kern_shutdown.c:542
#3  0xc0148192 in db_panic () at /usr/src/sys/ddb/db_command.c:448
#4  0xc0147fcc in db_command (last_cmdp=0xc037f9a0, cmd_table=0x0,
aux_cmd_tablep=0xc0376fb8, aux_cmd_tablep_end=0xc0376fbc)
at /usr/src/sys/ddb/db_command.c:346
#5  0xc014820a in db_command_loop () at /usr/src/sys/ddb/db_command.c:470
#6  0xc014af96 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72
#7  0xc0301697 in kdb_trap (type=12, code=0, regs=0xeb3b1780)
at /usr/src/sys/i386/i386/db_interface.c:166
#8  0xc031a590 in trap_fatal (frame=0xeb3b1780, eva=0)
at /usr/src/sys/i386/i386/trap.c:839
#9  0xc031a2da in trap_pfault (frame=0xeb3b1780, usermode=0, eva=52)
at /usr/src/sys/i386/i386/trap.c:758
#10 0xc0319e95 in trap (frame=
  {tf_fs = -1038483432, tf_es = 16, tf_ds = -1070202864, tf_edi = 
158, tf_esi = 52, tf_ebp = -348448800, tf_isp = -348448852, tf_ebx = 0, 
tf_edx = -966573056, tf_ecx = -966602272, tf_eax = -966602272, tf_trapno 
= 12, tf_err = 0, tf_eip
= -1071961914, tf_cs = 8, tf_eflags = 66178, tf_esp = 0, tf_ss = 
-1070141731})
at /usr/src/sys/i386/i386/trap.c:445
#11 0xc0302ff8 in calltrap () at {standard input}:97
#12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158
#13 0xc021bcfc in vn_open_cred (ndp=0xeb3b1a44, flagp=0xeb3b1a0c, cmode=0,
cred=0xc2195e80) at /usr/src/sys/kern/vfs_vnops.c:185
#14 0xc6acffb4 in ?? ()
#15 0xc01a06b3 in closef (fp=0x2, td=0x0) at vnode_if.h:1225
#16 0xc01a0054 in fdfree (td=0xc662d1e0)
at /usr/src/sys/kern/kern_descrip.c:1433
#17 0xc01a5da2 in exit1 (td=0xc662d1e0) at /usr/src/sys/kern/kern_exit.c:254
#18 0xc01a5b11 in sys_exit () at /usr/src/sys/kern/kern_exit.c:116
#19 0xc031ab56 in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 11095, 
tf_ebp =
-1077937128, tf_isp = -348447372, tf_ebx = 679838148, tf_edx = 
679837268, tf_ecx = 19, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 
680166719, tf_cs = 31, tf_eflags = 582, tf_esp = -1077937172, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#20 0xc030304d in Xint0x80_syscall () at {standard input}:139
---Can't read userspace from dump, or kernel process---

(kgdb) up 12
#12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158
158 FILEDESC_LOCK(fdp);
(kgdb) list
153 #endif
154
155 /*
156  * Get starting point for the translation.
157  */
158 FILEDESC_LOCK(fdp);
159 ndp->ni_rootdir = fdp->fd_rdir;
160 ndp->ni_topdir = fdp->fd_jdir;
161
162 dp = fdp->fd_cdir;

(kgdb) print ndp
$2 = (struct nameidata *) 0x9e

(kgdb) print fdp
$1 = (struct filedesc *) 0x34
(kgdb)

(kgdb) print p
$3 = (struct proc *) 0x0

(kgdb) print td
$5 = (struct thread *) 0xc662d1e0

(kgdb) print *td
$7 = {td_proc = 0xc66307f0,
[...]

Very strange. namei() does essentially the following:

	p = td->td_proc;
	fdp = p->p_fd;

td->td_proc seems reasonable, but p is 0. No idea how this could happen, 
any guesses?

Thanks,
Lars
--
Lars Eggert <[EMAIL PROTECTED]>   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signat

Re: background fsck deadlocks with ufs2 and big disk

[Darryl Okahata]

Brad Knowles <[EMAIL PROTECTED]> wrote:

>   You know, vinum & softupdates have had bad interactions with each 
> other for as long as I can remember.  Has this truly been a 
> consistent thing (as I seem to recall), or has this been an 
> on-again/off-again situation?

 Ah, yaaah.  Hmm 

 This is the first I've heard of that, but I can see how that could
be.  Could vinum be considered to be a form of (unintentional)
write-caching?  

 That might explain how the filesystem got terribly hosed, but it
doesn't help with the panic.  Foo.

[ This is on a system that's been running in the current state for
  around a month.  So far, it's panic'd once (a week or so ago), and so
  I don't have any feel for long-term stability.  We'll see how it
  goes.  ]

-- 
Darryl Okahata
[EMAIL PROTECTED]

DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.

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

UFS2 regression tests?

[John De Boskey]

Hi Folks,

   I've just put together a 1.7TB filesystem and was looking for some
regression tests to run against it. Looking through the mailing lists
doesn't turn up anything, nor does a websearch (at least for the keywords
I tried).

   So, does anyone have any comments/ideas on a good way to test the
new system? 

Thanks,
John

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

Realtek 8139B detected

[Martin Minkus]

During boot, i get the following:

rl0:  port 0x6100-0x61ff mem
0xe1001000-0xe10010ff ir
q 10 at device 14.0 on pci0
rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode
rl0: Ethernet address: 00:00:21:f2:a5:47
miibus0:  on rl0
rlphy0:  on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl1:  port 0x6200-0x62ff mem
0xe100-0xe1ff ir
q 12 at device 15.0 on pci0
rl1: Realtek 8139B detected. Warning, this may be unstable in autoselect mode
rl1: Ethernet address: 00:00:21:f4:d8:7d
miibus1:  on rl1
rlphy1:  on miibus1
rlphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ed0:  port 0x6300-0x631f irq 5 at
device 16.
0 on pci0
ed0: address 00:40:05:3b:eb:c9, type NE2000 (16 bit)

And i basically find that my realtek network cards are useless. I can
manually set them using ifconfig to use 100baseTX, etc, but they are NOT
very happy in 100mbit mode, nor will they work in full duplex. (This
evidence is supported by me looking at the LEDs that are illuminated on
the switch).

In FreeBSD 4.0 to 4.7-STABLE this has never been a problem.

Why is the driver broken in 5.0? We are going backwards now? ;)

I simply cannot make any realtek cards work. My only other cards are
crappy old NE2000 compatibles (ISA's!) that are laying around, and haven't
been used in a few years. And yeah, they are only 10mbit :/

What is going on?

I really want to start upgrading to 5.0 (There are no other issues, and
some people i know have been running 5.0-CURRENT ever since work on 5.0
began).

Martin.


Martin Minkus
Geac Enterprise Solutions
208 Greenhill Road, Eastwood 5063, South Australia
Tel: +61 8 8372 6111 / Fax: +61 8 8372 6196
Email: [EMAIL PROTECTED]



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

Re: UFS2 regression tests?

[Brad Knowles]

At 7:17 PM -0500 2003/02/19, John De Boskey wrote:


So, does anyone have any comments/ideas on a good way to test the
 new system?


	You could always set it up as a full-feed USENET news server. 
Should be able to fill that sucker up in two or three days.  ;-)

	Perhaps a freenet or other p2p filesharing server?

	You could also set it up as a freely available anonymous ftp 
read/write server.

	Or maybe a mirror of the various popular anonymous ftp sites out 
there?  At least that'd give you a lot of data to write


	Perhaps you want to give Bonnie++, IOZone, IOBench, etc... a 
really big test set?  Perhaps even set them up to run in continuous 
mode, so as to really thrash your disks as much as possible as 
quickly as possible?

--
Brad Knowles, <[EMAIL PROTECTED]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++)

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

Re: ACPI thermal panics ThinkPad 600X

[Kevin Oberman]

> Date: Mon, 17 Feb 2003 23:22:28 +0100 (MET)
> From: [EMAIL PROTECTED] (Joerg Wunsch)
> Sender: [EMAIL PROTECTED]
> 
> "Matthew N. Dodd" <[EMAIL PROTECTED]> wrote:
> 
> > My only outstanding issue is that I can't suspend if an application
> > is holding /dev/dsp or /dev/audio open.
> 
> Can you suspend from within graphics mode?  I can't seem to do that,
> neither with APM nor with ACPI.  In some case, i've seen four
> horizontal lines upon wakeup, in other cases, the graphics display
> gets restored correctly, but the machine still locks up (probably in
> APM BIOS, not even the lock key LEDs react, but Fn works).
> 
> Suspending from within text mode always works.  The graphics mode
> problem is particularly annoying if the system enters auto-suspend
> on a low battery condition...

Have you tried using APMD to put the display into text mode when
suspending? This si not my favorite way to do things, but it should
work a lot better than nothing.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]  Phone: +1 510 486-8634

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

Re: UFS2 regression tests?

[Wesley Morgan]

On Wed, 19 Feb 2003, John De Boskey wrote:

> Hi Folks,
>
>I've just put together a 1.7TB filesystem and was looking for some
> regression tests to run against it. Looking through the mailing lists
> doesn't turn up anything, nor does a websearch (at least for the keywords
> I tried).
>
>So, does anyone have any comments/ideas on a good way to test the
> new system?

How about getting some tarballs full of tons of files, extracting them,
deleting and randomly powering down forcing an fsck... :p

Not sure how much "regression" this provides but you're fairly likely to
break something!

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

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

Re: UFS2 regression tests?

[Brad Knowles]

At 7:58 PM -0500 2003/02/19, Wesley Morgan wrote:


 How about getting some tarballs full of tons of files, extracting them,
 deleting and randomly powering down forcing an fsck... :p


	Better yet, get that sample 1.7KB zip file that extracts out to 
hundreds of GB, and really thrash the system by doing parallel 
extracts of multiple copies of it, and make sure that you've got 
enough going at the same time that the result would be far larger 
than your available disk space.  That should be fun!

 Not sure how much "regression" this provides but you're fairly likely to
 break something!


	Yeah, especially if it's UFS2, you're doing softupdates with 
background fsck, and you've used vinum to build the large logical 
volume.  ;-)

--
Brad Knowles, <[EMAIL PROTECTED]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+() DI+() D+(++) G+() e++> h--- r---(+++)* z(+++)

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

Re: UFS2 regression tests?

[John De Boskey]

- Brad Knowles's Original Message -
>   Yeah, especially if it's UFS2, you're doing softupdates with 
> background fsck, and you've used vinum to build the large logical 
> volume.  ;-)

   Actually, I didn't say how the volume was put together :-)  It
is currently a Raid50 consisting of 3 Raid5 sets. It is hanging
off of an Adaptec 5400S controller.

   I realize I can probably "break" the system doing abnormal
things to it, but I'm more interested (at least for now) in
regression style testing.

-John

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

Re: UFS2 regression tests?

[Mike Barcroft]

John De Boskey <[EMAIL PROTECTED]> writes:
> Hi Folks,
> 
>I've just put together a 1.7TB filesystem and was looking for some
> regression tests to run against it. Looking through the mailing lists
> doesn't turn up anything, nor does a websearch (at least for the keywords
> I tried).
> 
>So, does anyone have any comments/ideas on a good way to test the
> new system? 

src/tools/regression/fsx

Best regards,
Mike Barcroft

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

Re: UFS/SOFTUPDATE inconsistency

[Evgueni Gavrilov]

[... snip ...]
PP> UNEXPECTED SOFT UPDATE INCONSISTENCY
PP> CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS files
[... snip ...]
PP> any on how to fix it?
I got the same bug. Machine got grozen without panic (it didn't restarted itself :-( 
). Of course, there was no crash dump.


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

Unable to do a clean reboot

[David Kleiner]

Hi,

Since I went to -current by way of 5.0-Rel, I was unable to
do a clean shutdown or reboot.  No matter how I tried it, 
2-8 buffers always remain there during sync'ing.  

It goes like this:

Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...stopped

syncing disks, buffers remaining... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
giving up on 2 buffers


wallaby# uname -a
FreeBSD wallaby.pacbell.net 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Tue Feb 18 21:06:18 
PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/W  i386

It's a PCGR505-TE Sony Vaio laptop with this disk:

ad0: 38154MB  [77520/16/63] at ata0-master UDMA100

Any suggestions?

Thank you,

David

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

Re: Page fault on disk-less machine

[Terry Lambert]

Poul-Henning Kamp wrote:
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x34

This is the same problem that the other people were complaining
about the other day.  It's interesting to note the third argument
to namei() is not zero in your case.


> _mtx_lock_flags(34,0,c02a5f56,9e,c0d9e1e0) at 0xc018fd20 = _mtx_lock_flags+0x40
> namei(c5fd29b8,c5fd2c34,c044,c0570d00,c0d9e1e0) at 0xc01de06d = namei+0x16d

Any chance of a "gdb -k" and a "list namei+0x16d"?

-- Terry

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

Re: Page fault on disk-less machine

[Terry Lambert]

Lars Eggert wrote:
> Poul-Henning Kamp wrote:
> > Fatal trap 12: page fault while in kernel mode
> 
> FWIW, Craig Boston and me see the same panics (threads on -current:
> "panic starting gnome" and "VFS panic (possibly NFS-locking related?)").

Have you "gdb -k" list'ed the namei code in question yet?

Per my last posting on this subject, note that Poul's offset into
namei is different than the one you gave.

If you could both provide this information, it would probably
triangulate the problem immediately.

Thanks,
-- Terry

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

Re: panic starting gnome

[Craig Boston]

On Wed, 2003-02-19 at 16:44, Lars Eggert wrote:
> #11 0xc0302ff8 in calltrap () at {standard input}:97
> #12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158
> #13 0xc021bcfc in vn_open_cred (ndp=0xeb3b1a44, flagp=0xeb3b1a0c, cmode=0,
>  cred=0xc2195e80) at /usr/src/sys/kern/vfs_vnops.c:185
> #14 0xc6acffb4 in ?? ()
> #15 0xc01a06b3 in closef (fp=0x2, td=0x0) at vnode_if.h:1225
> #16 0xc01a0054 in fdfree (td=0xc662d1e0)
>  at /usr/src/sys/kern/kern_descrip.c:1433
> #17 0xc01a5da2 in exit1 (td=0xc662d1e0) at /usr/src/sys/kern/kern_exit.c:254

Well, I haven't had much luck tracking down the exact cause.  For some
reason I haven't been able to figure out, all of my crash dumps jump
directly from vn_open_cred (line 185 of vfs_vnops.c) to calltrap().  The
namei call doesn't show up in the stack at all, almost like the function
is being inlined.  I'm only using -O, which shouldn't inline anything
not explicitly declared as such.

Anyway, using a cvsup binary search I've managed to narrow it down
some.  The problem did not exist before midnight UTC on 2003-04-15.  It
does exist on midnight UTC 2003-04-16.  I've been digging through the
commit logs for that day, but it seems it was a busy day for the VFS
code with lots of commits.  Since it always happens after an fdfree(),
I'm leaning toward a large (number of files) commit by alfred@ having to
do with a lock order reversal and adding a mutex associated with freeing
filedesc structures.  Just a guess, though.

Reproducing the problem seems to be as simple as killing any process
that has an open, locked file on an NFS volume.  A simple

gconfd-1 &
sleep 5; killall -9 gconfd-1

does it every time for me.  I assume this would also happen if a process
calls exit() without closing all of it's fds first; probably why
starting GNOME or booting diskless is enough to tickle it.

Craig


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

Re: panic starting gnome

[Terry Lambert]

Lars Eggert wrote:
> Terry Lambert wrote:
> > Debug:
>  >
> [excellent kernel-debugging recipe snipped]
> 
> Here's a backtrace of a crashdump that should be more helpful:

[ ... ]

> (kgdb) up 12
> #12 0xc02098a4 in namei (ndp=0x9e) at /usr/src/sys/kern/vfs_lookup.c:158
> 158 FILEDESC_LOCK(fdp);
> (kgdb) list
> 153 #endif
> 154
> 155 /*
> 156  * Get starting point for the translation.
> 157  */
> 158 FILEDESC_LOCK(fdp);
> 159 ndp->ni_rootdir = fdp->fd_rdir;
> 160 ndp->ni_topdir = fdp->fd_jdir;
> 161
> 162 dp = fdp->fd_cdir;
> 
> (kgdb) print ndp
> $2 = (struct nameidata *) 0x9e
> 
> (kgdb) print fdp
> $1 = (struct filedesc *) 0x34
> (kgdb)
> 
> (kgdb) print p
> $3 = (struct proc *) 0x0
> 
> (kgdb) print td
> $5 = (struct thread *) 0xc662d1e0
> 
> (kgdb) print *td
> $7 = {td_proc = 0xc66307f0,
> [...]
> 
> Very strange. namei() does essentially the following:
> 
> p = td->td_proc;
> fdp = p->p_fd;
> 
> td->td_proc seems reasonable, but p is 0. No idea how this could happen,
> any guesses?

Cool.

This is not where I was guessing it was at, at all.  8-) 8-).

There's a commit that Alfred made last Friday night that might
have something to do with it.  It was an attempt to fix a lock
order reversal between "PROC/filedesc", according to the commit,
and it introduced "fdesc_mtx".

If you grep for that everywhere, and then annotate the involved
files, it should be pretty obvious which changes to revert to see
if this is the case (1.50->1.49 of /sys/sys/filedesc.h, etc.).

It may also be an issue with some of the recent KSE commits
over the last weekend missing an assignment on a context switch.

Probably the easiest thing to do, if you can repeat the problem
reliably, is to bsearch, starting 8 days days ago, for the commit
that broke the camel's back.

It's really tempting to make a script that's capable of carrying
out a /usr/src/sys bsearch semi-automatically, because people are
really hesistant to use this approach for solving problems, even
though it only requires O(log2(N)) reboots to find it...


-- Terry

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

Re: Page fault on disk-less machine

[Craig Boston]

On Wed, 2003-02-19 at 21:48, Terry Lambert wrote:
> Lars Eggert wrote:
> > Poul-Henning Kamp wrote:
> > > Fatal trap 12: page fault while in kernel mode
> > 
> > FWIW, Craig Boston and me see the same panics (threads on -current:
> > "panic starting gnome" and "VFS panic (possibly NFS-locking related?)").
> 
> Have you "gdb -k" list'ed the namei code in question yet?
> 
> Per my last posting on this subject, note that Poul's offset into
> namei is different than the one you gave.

Mine is different as well: 0x12c, and on a cmpxchgl instruction (I know
that doesn't help any ;)

But:
(kgdb) list namei+0x12c
Junk at end of line specification.
(kgdb) 

Am I doing something wrong?

Craig


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

Re: Page fault on disk-less machine

[Scott Long]

Guys, this problem has already been identified.  I posted a
patch last night to cvs-all@ that fixes this, although it's
still not totally correct so I haven't committed it yet.

Scott

Craig Boston wrote:

On Wed, 2003-02-19 at 21:48, Terry Lambert wrote:


Lars Eggert wrote:


Poul-Henning Kamp wrote:


Fatal trap 12: page fault while in kernel mode


FWIW, Craig Boston and me see the same panics (threads on -current:
"panic starting gnome" and "VFS panic (possibly NFS-locking related?)").


Have you "gdb -k" list'ed the namei code in question yet?

Per my last posting on this subject, note that Poul's offset into
namei is different than the one you gave.



Mine is different as well: 0x12c, and on a cmpxchgl instruction (I know
that doesn't help any ;)

But:
(kgdb) list namei+0x12c
Junk at end of line specification.
(kgdb) 

Am I doing something wrong?

Craig


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


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

Re: Realtek 8139B detected

[Andrew Kenneth Milton]

+---[ Martin Minkus ]--
| During boot, i get the following:
| 

[snip]

| I really want to start upgrading to 5.0 (There are no other issues, and
| some people i know have been running 5.0-CURRENT ever since work on 5.0
| began).

I found that if I tried to specify any media or mediaopt options to ifconfig
that the RL's would refuse to find carrier (das blinkenlights on the switch).

Lines like the following simply don't work;

ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0 media auto mediaopt full-duplex"
ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0 media 100BaseTX mediaopt 
full-duplex"

whether you specify auto or specify a media.

However, if I just leave the card alone;

ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0"

It will come up by itself in 100BaseTX full-duplex on its own first time
every time.

It's something to try at least I suppose.

-- 
Totally Holistic Enterprises Internet|  | Andrew Milton
The Internet (Aust) Pty Ltd  |  M:+61 416 022 411   |
ACN: 082 081 472 ABN: 83 082 081 472 |[EMAIL PROTECTED]| Carpe Daemon

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

Re: panic starting gnome

[Terry Lambert]

Craig Boston wrote:
> Well, I haven't had much luck tracking down the exact cause.  For some
> reason I haven't been able to figure out, all of my crash dumps jump
> directly from vn_open_cred (line 185 of vfs_vnops.c) to calltrap().  The
> namei call doesn't show up in the stack at all, almost like the function
> is being inlined.  I'm only using -O, which shouldn't inline anything
> not explicitly declared as such.

Nope.  The problem is a NULL pointer dereference, apparently into
the proc structure, which is a NULL proc pointer.

> Anyway, using a cvsup binary search I've managed to narrow it down
> some.  The problem did not exist before midnight UTC on 2003-04-15.  It
> does exist on midnight UTC 2003-04-16.  I've been digging through the
> commit logs for that day, but it seems it was a busy day for the VFS
> code with lots of commits.  Since it always happens after an fdfree(),
> I'm leaning toward a large (number of files) commit by alfred@ having to
> do with a lock order reversal and adding a mutex associated with freeing
> filedesc structures.  Just a guess, though.

FWIW, I arrived at the same place, given Lars' debugging information,
though it was only my most likely suspect.  There are some changes
that went in for KSE, as well, but I'm pretty sure they were after
last Wednesday.


> Reproducing the problem seems to be as simple as killing any process
> that has an open, locked file on an NFS volume.  A simple
> 
> gconfd-1 &
> sleep 5; killall -9 gconfd-1
> 
> does it every time for me.  I assume this would also happen if a process
> calls exit() without closing all of it's fds first; probably why
> starting GNOME or booting diskless is enough to tickle it.

Yes, this is most likely.

-- Terry

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

Re: Page fault on disk-less machine

[Terry Lambert]

Craig Boston wrote:
> 
> On Wed, 2003-02-19 at 21:48, Terry Lambert wrote:
> > Lars Eggert wrote:
> > > Poul-Henning Kamp wrote:
> > > > Fatal trap 12: page fault while in kernel mode
> > >
> > > FWIW, Craig Boston and me see the same panics (threads on -current:
> > > "panic starting gnome" and "VFS panic (possibly NFS-locking related?)").
> >
> > Have you "gdb -k" list'ed the namei code in question yet?
> >
> > Per my last posting on this subject, note that Poul's offset into
> > namei is different than the one you gave.
> 
> Mine is different as well: 0x12c, and on a cmpxchgl instruction (I know
> that doesn't help any ;)
> 
> But:
> (kgdb) list namei+0x12c
> Junk at end of line specification.
> (kgdb)
> 
> Am I doing something wrong?

My bad:

list *namei+0x12c

Note the asterisk to dereference before the add.

-- Terry

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

Re: Page fault on disk-less machine

[Terry Lambert]

Scott Long wrote:
> Guys, this problem has already been identified.  I posted a
> patch last night to cvs-all@ that fixes this, although it's
> still not totally correct so I haven't committed it yet.

This one, I imagine.  Thanks!

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1225336+0+current/cvs-all

It wasn't clear that this was the same problem, with the other
recent potentially destabilizing commits.  I guess PHK, Lars,
and Craig should try applying this, and seeing if it fixes things
for them...

-- Terry

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

Re: Page fault on disk-less machine

[Lars Eggert]

On 2/19/2003 8:23 PM, Scott Long wrote:

Guys, this problem has already been identified.  I posted a
patch last night to cvs-all@ that fixes this, although it's
still not totally correct so I haven't committed it yet.


Great, thanks!

Though it might have been a good idea to CC current@ - I'd have seen it 
there. (I filter cvs-all@ for pieces of the tree I'm interested in, and 
your mail must have been nuked.)

Lars
--
Lars Eggert <[EMAIL PROTECTED]>   USC Information Sciences Institute


smime.p7s
Description: S/MIME Cryptographic Signature

îÅÚÁÂÙ×ÁÅÍÙÅ ÔÕÒÙ × úÁÐÏÌÑÒØÅ

[îÅÉÚ×ÅÓÔÎÁÑ ÚÅÍÌÑ]

îÅÚÁÂÙ×ÁÅÍÙÅ ÔÕÒÙ × úÁÐÏÌÑÒØÅ - http://koresh.ru/terra/tour.shtml
éÚ×ÉÎÑÅÍÓÑ ÚÁ ×ÏÚÍÏÖÎÙÅ ÐÒÅÄÏÓÔÁ×ÌÅÎÎÙÅ ÎÅÕÄÏÂÓÔ×Á.
åÓÌÉ ÷Ù ÈÏÔÉÔÅ ÉÓËÌÀÞÉÔØ Ó×ÏÊ e-mail ÁÄÒÅÓ ÉÚ ÒÁÓÓÙÌËÉ, ÐÏÖÁÌÕÊÓÔÁ, ÕÄÁÌÉÔÅ ÅÇÏ ÚÄÅÓØ: 








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

Re: Realtek 8139B detected

[Russell L. Carter]

Well, um, if you look for messages from me last June and then again
several times recently you'll find we are a club of three, at least.

I can't actually manually ifconfig it either, it comes up the
first time fine, but I can wedge my machine with a few large
transfers.

I got a couple of hints via email about crappy RealTek errata
and I spent an hour squinting at the diffs between -stable where
it works flawlessly, and -current, but could not see anything
that was related.  But I'm lousy at drivers.

I was actually pondering whether to ditch the idea of using the
on-board rl, and switch to a wifi card or something else, since
it's back in -stable now, and this is an acpi only laptop.

Best,
Russell


: +---[ Martin Minkus ]--
: | During boot, i get the following:
: | 
: 
: [snip]
: 
: | I really want to start upgrading to 5.0 (There are no other issues, and
: | some people i know have been running 5.0-CURRENT ever since work on 5.0
: | began).
: 
: I found that if I tried to specify any media or mediaopt options to ifconfig
: that the RL's would refuse to find carrier (das blinkenlights on the switch).
: 
: Lines like the following simply don't work;
: 
: ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0 media auto mediaopt full-duplex"
: ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0 media 100BaseTX mediaopt 
:full-duplex"
: 
: whether you specify auto or specify a media.
: 
: However, if I just leave the card alone;
: 
: ifconfig_rl0="inet 10.10.10.10 netmask 255.255.255.0"
: 
: It will come up by itself in 100BaseTX full-duplex on its own first time
: every time.
: 
: It's something to try at least I suppose.
: 
: -- 
: Totally Holistic Enterprises Internet|  | Andrew Milton
: The Internet (Aust) Pty Ltd  |  M:+61 416 022 411   |
: ACN: 082 081 472 ABN: 83 082 081 472 |[EMAIL PROTECTED]| Carpe Daemon
: 
: To Unsubscribe: send mail to [EMAIL PROTECTED]
: with "unsubscribe freebsd-current" in the body of the message



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

Re: Cardbus-attached USB controller

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Bob Bishop <[EMAIL PROTECTED]> writes:
: Would someone like to give me a clue how to plumb this thing in? TIA

Index: ohci_pci.c
===
RCS file: /cache/ncvs/src/sys/dev/usb/ohci_pci.c,v
retrieving revision 1.29
diff -u -r1.29 ohci_pci.c
--- ohci_pci.c  29 Jan 2003 00:13:29 -  1.29
+++ ohci_pci.c  20 Feb 2003 06:09:32 -
@@ -314,3 +314,4 @@
 static devclass_t ohci_devclass;
 
 DRIVER_MODULE(ohci, pci, ohci_driver, ohci_devclass, 0, 0);
+DRIVER_MODULE(ohci, cardbus, ohci_driver, ohci_devclass, 0, 0);

Warner

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

Re: 5.0R - panic: bwrite: buffer is not busy

[phk]

In message <[EMAIL PROTECTED]>, Patric Mrawek writes:
>I am seeing a reproducible panic with
>
>FreeBSD talisker 5.0-RELEASE FreeBSD 5.0-RELEASE #5: Wed Jan 29 10:49:32 CET 2003
>root@talisker:/usr/src/sys/i386/compile/TALISKER i386
>
>What I've done is:
>- kldload uvisor.ko
>- running »/usr/sbin/usbd -d -v«
>- running »jpilot-sync -d -l -p /dev/ucom0«
>- hitting the sync-button from my visor several times
>
>After hitting the sync-button 5 to 10 times my box panics.

it looks like a device disappeared while you had it open.

I'll commit a workaround for this later today.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: top-of-tree alpha kernel panics during boot

[Kris Kennaway]

On Wed, Feb 19, 2003 at 08:42:40PM +0100, Dag-Erling Smorgrav wrote:

>  3) a fresh kernel without pcm boots but exhibits the same symptoms
> kris reported, i.e. programs segfaulting for no apparent reason;
> if / when they produce a core file, it is corrupted and useless
> for debugging.  I suspect a problem in the I/O system, possibly
> similar to the one tegge discovered and fixed last week.

My problem (seen on the alpha package cluster in the chroots used to
build packages) may have been a bad userland.  I used a snapshot from
snapshots.jp.freebsd.org to populate the chroots and saw tons of
sig11s during the package builds, but when I built a world myself and
used that the problems seem to have ceased.  I haven't updated the
kernel on those machines.

Kris



msg52746/pgp0.pgp
Description: PGP signature

Re: strange dump/restore behaviour

[Kirk McKusick]

To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: strange dump/restore behaviour
From: Dag-Erling Smorgrav <[EMAIL PROTECTED]>
Date: Thu, 09 Jan 2003 16:41:10 +0100

This happened while copying data over to a new disk (mounted on /mnt
and /mnt/usr; the original disk has only one partition).  The machine
was in single-user mode, but / was mounted read-write due to restore's
insistance on placing temporary files in /tmp (I found out later that
it respects TMPDIR, though the man page doesn't mention it).

root@dsa /mnt# dump -0Laf- / | restore -rf-
  DUMP: Date of this level 0 dump: Thu Jan  9 16:11:42 2003
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping snapshot of /dev/da0a (/) to standard output
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 1838856 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
warning: ./usr: File exists
expected next file 4, got 3
[...]

I can imagine that the file that caused the warning message was one of
restore's temporary files, but a) I've never seen this before, and b)
isn't -L supposed to prevent just that?

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

Sorry for the slow response. I tend to get behind on my freebsd.org
email.

The warning comes about because you had already created /mnt/usr.
Since you were doing a full restore, you are getting a warning
that the usr directory already exists when restore tries to create
it. It complains again about finding an already existing inode (3
which was presumably the usr directory in the original dump).
Neither of these are problematic or affected your restore.

Kirk McKusick

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

Re: top-of-tree alpha kernel panics during boot

[Dag-Erling Smorgrav]

Andrew Gallatin <[EMAIL PROTECTED]> writes:
> Can you post your kernel config please, along with with, if any,
> CPUTYPE you have set in make.conf and a description of your machine
> (mem size in particular)?  

Digital Personal WorkStation 600au, 598MHz
8192 byte page size, 1 processor.
CPU: EV56 (21164A) major=7 minor=0 extensions=0x1
OSF PAL rev: 0x100020116
real memory  = 266493952 (254 MB)
avail memory = 251985920 (240 MB)

des@dsa ~% grep CPU /etc/make.conf
CPUTYPE ?= ev56

Full dmesg (from a working kernel built from Jan 9th sources) and
kernel config attached.

Note that:

 1) the problem disappears if I remove the pcm driver from the kernel
(yet I don't think it's directly at fault since the panic happens
when the ess driver is about to be initialized)

 2) the problem also disappears if I enable KTR (see commented-out
entries in config file)

 3) a fresh kernel without pcm boots but exhibits the same symptoms
kris reported, i.e. programs segfaulting for no apparent reason;
if / when they produce a core file, it is corrupted and useless
for debugging.  I suspect a problem in the I/O system, possibly
similar to the one tegge discovered and fixed last week.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]


Copyright (c) 1992-2003 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 5.0-CURRENT #30: Thu Jan  9 13:58:33 CET 2003
[EMAIL PROTECTED]:/usr/src/sys/alpha/compile/DSA
Preloaded elf kernel "/boot/kernel.ok/kernel" at 0xfc77.
Digital Personal Workstation (Miata)
Digital Personal WorkStation 600au, 598MHz
8192 byte page size, 1 processor.
CPU: EV56 (21164A) major=7 minor=0 extensions=0x1
OSF PAL rev: 0x100020116
real memory  = 266493952 (254 MB)
avail memory = 251985920 (240 MB)
Initializing GEOMetry subsystem
cia0: <2117x Core Logic chipset>
cia0: Pyxis, pass 1
cia0: extended capabilities: 1
pcib0: <2117x PCI host bus adapter> on cia0
pci0:  on pcib0
dc0:  port 0x9000-0x907f mem 0x80151000-0x8015107f irq 0 at 
device 3.0 on pci0
dc0: interrupting at CIA irq 0
dc0: Ethernet address: 08:00:2b:86:88:55
miibus0:  on dc0
nsphy0:  on miibus0
nsphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0x90a0-0x90af,0x3f4-0x3f7,0x1f0-0x1f7 
irq 238 at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: interrupting at ISA irq 14
ata1: at 0x170 irq 15 on atapci0
ata1: interrupting at ISA irq 15
atapci1:  port 0x374-0x377,0x170-0x177 mem 
0x8014-0x8014 irq 239 at device 7.2 on pci0
atapci1: Busmastering DMA not configured
ohci0:  mem 0x8015-0x80150fff irq 234 at device 7.3 
on pci0
ohci0: interrupting at ISA irq 10
usb0: OHCI version 1.0, legacy support
usb0:  on ohci0
usb0: USB revision 1.0
uhub0: (0x1080) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
pcib1:  at device 20.0 on pci0
pci1:  on pcib1
isp0:  port 0x8000-0x80ff mem 
0x8001-0x80010fff irq 3 at device 4.0 on pci1
isp0: interrupting at CIA irq 3
atkbdc0:  at port 0x64,0x60 on isa0
atkbd0:  irq 1 on atkbdc0
atkbd0: interrupting at ISA irq 1
fdc0:  at port 
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: interrupting at ISA irq 6
mcclock0:  at port 0x70-0x71 on isa0
ppc0:  at port 0x3bc-0x3c3 irq 7 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
lpt0:  on ppbus0
lpt0: Polled port
ppi0:  on ppbus0
ppc0: interrupting at ISA irq 7
sio0 at port 0x3f8-0x3ff irq 4 on isa0
sio0: type 16550A, console
sio0: interrupting at ISA irq 4
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio1: interrupting at ISA irq 3
sbc0:  at port 0x220-0x22f irq 5 drq 1 on isa0
sbc0: interrupting at ISA irq 5
pcm0:  on sbc0
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "alpha"  frequency 599860139 Hz
Timecounters tick every 0.976 msec
Waiting 2 seconds for SCSI devices to settle
cd0 at isp0 bus 0 target 6 lun 0
cd0:  Removable CD-ROM SCSI-2 device 
cd0: 4.237MB/s transfers (4.237MHz, offset 8)
cd0: Attempt to query device size failed: NOT READY, Medium not present
da1 at isp0 bus 0 target 1 lun 0
da1:  Fixed Direct Access SCSI-2 device 
da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled
da1: 4341MB (8890760 512 byte sectors: 255H 63S/T 553C)
da0 at isp0 bus 0 target 0 lun 0
da0:  Fixed Direct Access SCSI-3 device 
da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled
da0: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C)
Mounting root from ufs:/dev/da0a

# Kernel configuration for dsa.thinksec.com

machine alpha
cpu EV5
options DEC_ST550
ident   DSA
maxusers0

makeoptions DEBUG=-g
options DDB
#optionsDEBUG_VFS_LOCKS
options INVARIANT_SUPPORT, INVARIANTS
#optionsWITNESS, WITNESS_SKIPSPIN

#option

Re: top-of-tree alpha kernel panics during boot

[Andrew Gallatin]

Dag-Erling Smorgrav writes:

 > #options CD9660  #kld

Do you preload any/all of the things you've marked as klds?

I've tried to duplicate your crash on my xp1000.  I've used your
kernel config file.  I've reduced my memory size to 254MB.
I've got roughly similar hardware (w/the exception of the chipset and
cpu).  The only thing I've not done is to preload any klds.

I don't doubt there's a problem, but I'm having a hell of a time
finding it :-(

Drew

Copyright (c) 1992-2003 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 5.0-CURRENT #2: Wed Feb 19 20:34:33 EST 2003
gallatin@monet:/usr/tmp/sys/alpha/compile/DES
Preloaded elf kernel "/kernel.test" at 0xfc762000.
ST6600
COMPAQ Professional Workstation XP1000, 500MHz
8192 byte page size, 1 processor.
CPU: EV6 (21264) major=8 minor=3 extensions=0x303
OSF PAL rev: 0x1001600020153
real memory  = 266338304 (254 MB)
avail memory = 251936768 (240 MB)
tsunami0: <21271 Core Logic chipset>
pcib0: <21271 PCI host bus adapter> on tsunami0
pci0:  on pcib0
isab0:  at device 7.0 on pci0
isa0:  on isab0
atapci0:  port 0x1-0x1000f,0x3f4-0x3f7,0x1f0-0x1f7 
irq 238 at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: interrupting at ISA irq 14
ata1: at 0x170 irq 15 on atapci0
ata1: interrupting at ISA irq 15
atapci1:  port 0x374-0x377,0x170-0x177 mem 
0x108-0x108 irq 239 at device 7.2 on pci0
atapci1: Busmastering DMA not configured
ohci0:  mem 0x109-0x1090fff irq 234 at device 7.3 
on pci0
ohci0: interrupting at ISA irq 10
usb0: OHCI version 1.0, legacy support
usb0:  on ohci0
usb0: USB revision 1.0
uhub0: (0x1080) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
pci0:  at device 13.0 (no driver attached)
pcib1: <21271 PCI host bus adapter> on tsunami0
pci1:  on pcib1
dc0:  port 0x1-0x1007f mem 0x1051000-0x10513ff irq 45 at 
device 3.0 on pci1
dc0: Ethernet address: 00:00:f8:71:ae:00
miibus0:  on dc0
dcphy0:  on miibus0
dcphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0: interrupting at TSUNAMI irq 45
isp0:  port 0x1000-0x10ff mem 
0x105-0x1050fff irq 47 at device 6.0 on pci1
isp0: interrupting at TSUNAMI irq 47
pcib2:  at device 8.0 on pci1
pci2:  on pcib2
atkbdc0:  at port 0x64,0x60 on isa0
atkbd0:  irq 1 on atkbdc0
atkbd0: interrupting at ISA irq 1
fdc0:  at port 
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: interrupting at ISA irq 6
mcclock0:  at port 0x70-0x71 on isa0
ppc0:  at port 0x3bc-0x3c3 irq 7 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
lpt0:  on ppbus0
lpt0: Polled port
ppi0:  on ppbus0
ppc0: interrupting at ISA irq 7
sio0 at port 0x3f8-0x3ff irq 4 on isa0
sio0: type 16550A, console
sio0: interrupting at ISA irq 4
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
sio1: interrupting at ISA irq 3
sbc0:  at port 0x220-0x22f irq 5 drq 1 on isa0
sbc0: interrupting at ISA irq 5
pcm0:  on sbc0
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "alpha"  frequency 53025 Hz
Timecounters tick every 0.976 msec
ad0: 9787MB  [19885/16/63] at ata0-slave WDMA2
acd0: CDROM  at ata0-master PIO4
Waiting 2 seconds for SCSI devices to settle
da0 at isp0 bus 0 target 0 lun 0
da0:  Fixed Direct Access SCSI-2 device 
da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled
da0: 4091MB (8380080 512 byte sectors: 255H 63S/T 521C)
da1 at isp0 bus 0 target 1 lun 0
da1:  Fixed Direct Access SCSI-2 device 
da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled
da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C)
da2 at isp0 bus 0 target 2 lun 0
da2:  Fixed Direct Access SCSI-2 device 
da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled
da2: 8678MB (17773524 512 byte sectors: 255H 63S/T 1106C)
Mounting root from ufs:/dev/da1a



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

Re: Simply impossible to format disk under current.

[phk]

In message <[EMAIL PROTECTED]>, David Gilbert writes:
>I ran into an interesting problem last night ... that was very
>frustrating.  I was recycling SCSI drives from some NetBSD machines
>(that were client boxes) to add to a RAID server running
>FreeBSD-5.0-RELEASE.
>
>It's simply impossible to format NetBSD drives under current.
>
>Let me expand on that.  /dev/da2 exists, but you can't say 'fdisk -I
>da2' ... fdisk says that /dev/da2 doesn't exist.  /dev/da2 (and
>/dev/da2c) isn't writable, so I can't blank the first few sectors.  I
>even tried this in single user mode.

/dev/da2 is always writable unless you have any of the partitions
open.

I guess you have whacked the disk now, so I won't be able to get
any debugging information.

In case of disk/GEOM related problems, I need the output from
dmesg
sysctl -b kern.geom.confxml
or I won't really be able to do debugging...


-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: Simply impossible to format disk under current.

[David Gilbert]

> "phk" == phk  <[EMAIL PROTECTED]> writes:

phk> /dev/da2 is always writable unless you have any of the partitions
phk> open.

The error was that /dev/da2 didn't exist.  I was confused too.  

fdisk da2  # worked, displyed one slice (3) that was NetBSD
fdisk -I da2   # error, /dev/da2 doesn't exist

... it seemed like anything that wrote to da2 would fail, but read
worked.

phk> I guess you have whacked the disk now, so I won't be able to get
phk> any debugging information.

In the process of determining that it worked with 4.7-RELEASE I did
format the disk, so I'm not sure that the disk itself is useful.

phk> In case of disk/GEOM related problems, I need the output from
phk> dmesg sysctl -b kern.geom.confxml or I won't really be able to do
phk> debugging...

I would bet that any NetBSD root disk installed by the NetBSD
installer would exhibit the same problems.  It should be easy to
duplicate.  I don't have a spare disk handy right now... but I might
be able to do this in a week or two.  I would expect that you can do
this on your bench, tho.

There wasn't anything special about the NetBSD disks ... they had just
been formatted through the install process that NetBSD does.  1.5.2, I
think.

Dave.

-- 

|David Gilbert, Velocet Communications.   | Two things can only be |
|Mail:   [EMAIL PROTECTED] |  equal if and only if they |
|http://daveg.ca  |   are precisely opposite.  |
=GLO

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

RE: Unable to do a clean reboot

[Tony Harverson]

Hey There..

I would guess you're using SCHED_ULE in your Kernel config?  It seems to
cause shutdown problems that haven't been addressed yet..

Tony

-Original Message-
From: David Kleiner [mailto:[EMAIL PROTECTED]] 
Sent: 20 February 2003 05:45
To: [EMAIL PROTECTED]
Subject: Unable to do a clean reboot


Hi,

Since I went to -current by way of 5.0-Rel, I was unable to
do a clean shutdown or reboot.  No matter how I tried it, 
2-8 buffers always remain there during sync'ing.  

It goes like this:

Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
Waiting (max 60 seconds) for system process `bufdaemon' to
stop...stopped Waiting (max 60 seconds) for system process `syncer' to
stop...stopped

syncing disks, buffers remaining... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
2 2 giving up on 2 buffers


wallaby# uname -a
FreeBSD wallaby.pacbell.net 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Tue Feb
18 21:06:18 PST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/W
i386

It's a PCGR505-TE Sony Vaio laptop with this disk:

ad0: 38154MB  [77520/16/63] at ata0-master UDMA100

Any suggestions?

Thank you,

David

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

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

Panic induced by background fsck.

[ianf]

Hi

Several seconds into background fsck, this happens.  It's easily
repeatable by enabling background fsck and booting after an unclean
shutdown.

Kernel is 2003-02-19 from source checked out on that day (SMP).
The filesystems are UFS1 with softupdates.

panic: vm_fault: fault on nofault entry, addr: c7c65000
cpuid = 0; lapic.id = 
Stack backtrace:
backtrace(c03185a5,0,c0325e37,d280258c,1) at backtrace+0x17
panic(c0325e37,c7c65000,2,d2802638,d2802628) at panic+0x10a
vm_fault(c082f000,c7c65000,2,0,c3908690) at vm_fault+0x1073
trap_pfault(d2802724,0,c7c65000,1db,c7c65000) at trap_pfault+0x161
trap(d2800018,d2800010,c3920010,c7c65000,0) at trap+0x3cd
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc02da907, esp = 0xd2802764, ebp = 0xd2802a3c ---
generic_bzero(c38f7000,80be140,70,1000,3e5428db) at generic_bzero+0xf
ffs_mount(c38f7000,c3a4c800,bfbffcc0,d2802bec,c3908690) at ffs_mount+0x638
vfs_mount(c3908690,c385e230,c3a4c800,1211000,bfbffcc0) at vfs_mount+0x83a
mount(c3908690,d2802d10,c032ba37,407,4) at mount+0xb8
syscall(2f,2f,2f,0,bfbffdc0) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (21), eip = 0x805636b, esp = 0xbfbffc0c, ebp = 0xbfbffd48 ---
Debugger("panic")
Stopped at  Debugger+0x55:  xchgl   %ebx,in_Debugger.0
db> call boot
panic: bremfree: bp 0xc75ab978 not locked
cpuid = 0; lapic.id = 
boot() called on cpu#0
Uptime: 2m43s
Dumping 191 MB


Ian

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

LOR in pcn driver (and pcn driver may be broken)

[ianf]

Hi

I got this yesterday on my SMP system current as of yesterday:

pcn0:  port 0xe800-0xe81f mem 0xea001000-0xea00101f irq 16 
at device 9.0 on pci0
../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from 
../../../pci/if_pcn.c:524
../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from 
../../../pci/if_pcn.c:524
lock order reversal
 1st 0xc3860e88 pcn0 (network driver) @ ../../../pci/if_pcn.c:524
 2nd 0xc0343660 allproc (allproc) @ ../../../kern/kern_fork.c:328
Stack backtrace:
backtrace(c031afb6,c0343660,c0317d4f,c0317d4f,c031615f) at backtrace+0x17
witness_lock(c0343660,8,c031615f,148,0) at witness_lock+0x660
_sx_xlock(c0343660,c031615f,148,fa,0) at _sx_xlock+0xb2
fork1(c033eae0,60034,0,c043d994,c0d16f6b) at fork1+0x23d
kthread_create(c01c5210,c0d16f00,c043d9c4,6,0) at kthread_create+0x48
ithread_create(c043d9f8,10,0,c02e0410,c02e03a0) at ithread_create+0xda
inthand_add(c0d00dc0,10,c0263da0,c3860800,4) at inthand_add+0x9e
nexus_setup_intr(c0d15880,c385f300,c38671c0,4,c0263da0) at nexus_setup_intr+0x85
bus_generic_setup_intr(c0d15800,c385f300,c38671c0,4,c0263da0) at 
bus_generic_setup_intr+0xa2
bus_generic_setup_intr(c0d15700,c385f300,c38671c0,4,c0263da0) at 
bus_generic_setup_intr+0xa2
bus_generic_setup_intr(c0d15680,c385f300,c38671c0,4,c0263da0) at 
bus_generic_setup_intr+0xa2
bus_setup_intr(c385f300,c38671c0,4,c0263da0,c3860800) at bus_setup_intr+0xa5
pcn_attach(c385f300,c380f098,c0335270,c0186b5e,c385f500) at pcn_attach+0x69b
device_probe_and_attach(c385f300,0,c043dc0c,c0186ce6,c0d15680) at 
device_probe_and_attach+0xb0
bus_generic_attach(c0d15680,0,58,c043dbfc,c0d15680,0) at bus_generic_attach+0x28
pci_attach(c0d15680,c380a098,c0335270,c0328e72,0) at pci_attach+0xa6
device_probe_and_attach(c0d15680,c382f070,c043dc78,c02e398f,c0d15700) at 
device_probe_and_attach+0xb0
bus_generic_attach(c0d15700,c0328e72,0,c043dc68,c0d15700) at bus_generic_attach+0x28
nexus_pcib_attach(c0d15700,c3834098,c0335270,c035ce00,c0d00290) at 
nexus_pcib_attach+0x8f
device_probe_and_attach(c0d15700,c0d15800,c043dcdc,c02ce29c,c0d15800) at 
device_probe_and_attach+0xb0
bus_generic_attach(c0d15800,0,c0d003a0,c0d0d280,c0d15800) at bus_generic_attach+0x28
legacy_attach(c0d15800,c382f098,c0335270,c3837170,c035cbe0) at legacy_attach+0x1c
device_probe_and_attach(c0d15800,c0d15880,c043dd2c,c02d5edc,c0d15880) at 
device_probe_and_attach+0xb0
bus_generic_attach(c0d15880,c0d15880,c043dd5c,c01ec8b0,c0d15880) at 
bus_generic_attach+0x28
nexus_attach(c0d15880,c3829098,c0335270,c032a7ac,0) at nexus_attach+0x1c
device_probe_and_attach(c0d15880,c033018c,c043dd80,c02c04ce,c0d15c00) at 
device_probe_and_attach+0xb0
root_bus_configure(c0d15c00,c032a7ac,0,c043dd98,c01b3225) at root_bus_configure+0x28
configure(0,43a000,43ac00,43a000,0) at configure+0x2e
mi_startup() at mi_startup+0xb5
begin() at begin+0x2c
../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from 
../../../pci/if_pcn.c:524
../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from 
../../../pci/if_pcn.c:524
../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from 
../../../pci/if_pcn.c:524
pcn0: Ethernet address: 00:60:b0:b6:d9:ee
miibus1:  on pcn0
lxtphy0:  on miibus1
lxtphy0:  100baseFX, 100baseFX-FDX, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 
auto
../../../vm/uma_core.c:1330: could sleep with "pcn0" locked from 
../../../pci/if_pcn.c:524

Also, the card sees link and correctly autodetects the link speed,
but the driver does not seem to be able to get packets onto the
wire, or read packets from the wire.

Ian

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

Re: The cbus driver for pc98

[Takahashi Yoshihiro]

In article <[EMAIL PROTECTED]>
"M. Warner Losh" <[EMAIL PROTECTED]> writes:

> Cbus is to ISA as CardBus is to PCI in many ways.  Cbus is very much
> like ISA in all but a few details.  CardBus is pci with a few twists
> and turns that differ.  If you look at how we've implemented cardbus,
> you'll see that we've tried to do it as a 'subclass' of the pci bus.
> We implement the PCI interfaces in the cardbus bus code, even though
> it is not really a pci bus.  I'd propose that cbus implements the ISA
> interfaces in a similar manner.

If my understanding is not a mistake, the CardBus specifications is
derived from the PCI.  Therefore, I can understand that the cardbus
driver depend on the pci driver.  But, the Cbus is NOT derived from
the ISA.  So, I think that the cbus driver should not depend on the
isa driver.

---
TAKAHASHI Yoshihiro <[EMAIL PROTECTED]>

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

modern (usb) webcam support?

[jacob rhoden]

My searches for information on webcam have not found much, except for some
sites which say FreeBSD does not support USB web cameras.

Is anyone currently working on support for this? Does anyone have any
ideas about where one could go to get information about where to start
if one was to start writing a driver?

(I am about to buy a webcam for use in windows, it would be nice if I
 could choose a webcam which someone is either writing a driver for
 or knows where i coudl get information on them so that I could
 try and write one).

Any info appreciated!

 - jacob

___
Jacob RhodenPhone: +61 3 9844 6102
ITS DivisionEmail: [EMAIL PROTECTED]
Melbourne University   Mobile: +61 403 788 386



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