Re: SiI3112 SATA controller problems - status

[Derek Ragona]

Søren,

The SATA seems better, but is still not working.  I tried the Oct 5 
snapshot, doing a clean install.  I CVSup'd and did
make buildworld
make buildkernel KERNCONF=GENERIC
make installkernel KERNCONF=GENERIC
reboot to single user
mount -a
swapon -a
mergemaster -p
make installworld

System has the same DMA write problems.  In this recent case it was 
installing termcap.  I tried the Oct 1 snapshot and it was the same, it 
errored in installworld installing tar.

The SATA is stabler as I can buildworld, but not stable enough to handle 
the installworld copies.

Here is what I copied from the console after it went into the debugger:
spec_getpages I/O Read failure(error=5)
vm_fault: pager read error
panic: initiate_write_inodeblock_ufs2: already started
Let me know if you want more information.  I will have to reinstall to get 
a dmesg, if you want a new one.

-Derek

At 04:09 PM 9/30/2003 -0500, Derek Ragona wrote:
Great news to hear Søren.

Do you know when a snapshot with the fix will be available?  Since I 
cannot complete a buildworld using the SATA drive without the fix.

Thanks for the fix.

-Derek

At 10:06 PM 9/30/2003 +0200, Soren Schmidt wrote:

I have now found a way to reproduce the DMA problems some setups seems
to be having with the SiI3112A SATA chip.
Now, if I use real SATA drives, (and I mean real SATA drives, the
WD Raptor fx is not a real SATA device but just a PATA device
with a build in PATA->SATA converter chip) it works just fine
no matter what I try.
If however I use an older PATA drive and a certain PATA->SATA "dongle"
(in this case 1 out of 4 samples) I can reproduce the problem pretty
easily.
This suggests to me that we are looking at a timing problem of sorts
the question is where.
I'll work on the problem as time permits...

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

SV: X does not work ... [alc@FreeBSD.org: cvs commit: src/sys/vmdevice_pager.c]

[Matt Douhan]

-Ursprungligt meddelande-
>Fran: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] Alan Cox
>
>This should resolve the problem starting X.
>
>- Forwarded message from Alan Cox <[EMAIL PROTECTED]> -
>
>X-Original-To: [EMAIL PROTECTED]
>Delivered-To: [EMAIL PROTECTED]
>Delivered-To: [EMAIL PROTECTED]
>From: Alan Cox <[EMAIL PROTECTED]>
>Date: Sun, 5 Oct 2003 15:23:44 -0700 (PDT)
>To: [EMAIL PROTECTED], [EMAIL PROTECTED],
>   [EMAIL PROTECTED]
>Subject: cvs commit: src/sys/vm device_pager.c
>X-FreeBSD-CVS-Branch: HEAD
>Precedence: bulk
>X-Loop: FreeBSD.ORG
>X-Virus-Scanned: by amavis-20030314-p2 at cs.rice.edu
>X-DCC--Metrics: cs.rice.edu 1067; Body=1 Fuz1=1 Fuz2=1
>
>alc 2003/10/05 15:23:44 PDT
>
>  FreeBSD src repository
>
>  Modified files:
>sys/vm   device_pager.c
>  Log:
>  The addition of a locking assertion to vm_page_zero_invalid() has
revealed
>  a long-time bug: vm_pager_get_pages() assumes that m[reqpage] contains a
>  valid page upon return from pgo_getpages().  In the case of the device
>  pager this page has been freed and replaced by a fake page.  The fake
page
>  is properly inserted into the vm object but m[reqpage] is left pointing
>  to a freed page.  For now, update m[reqpage] to point to the fake page.
>
>  Submitted by:   tegge
>
>  Revision  ChangesPath
>  1.69  +1 -0  src/sys/vm/device_pager.c


Yes this works for me


Regards

Matt

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

Re: recursed on non-recursive lock (sleep mutex) vm page queue mutex

[Alan Cox]

On Sat, Oct 04, 2003 at 11:31:33PM -0700, Kris Kennaway wrote:
> I don't think I've seen this one before (i386, kernel built Sep 17).
> Is it already fixed?
> 

No, not yet.

Regards,
Alan

> 
> recursed on non-recursive lock (sleep mutex) vm page queue mutex @ 
> /a/asami/portbuild/i386/src-client/sys/kern/vfs_bio.c:3630
> first acquired @ /a/asami/portbuild/i386/src-client/sys/vm/vm_pageout.c:403
> panic: recurse
> Debugger("panic")
> Stopped at  Debugger+0x54:  xchgl   %ebx,in_Debugger.0
> db> trace
> Debugger(c043582e,c04a70e0,c0438952,d7077940,100) at Debugger+0x54
> panic(c0438952,c044c2d9,193,c043b873,e2e) at panic+0xd5
> witness_lock(c04d5900,8,c043b873,e2e,1) at witness_lock+0x3b3
> _mtx_lock_flags(c04d5900,0,c043b873,e2e,0) at _mtx_lock_flags+0xba
> vm_hold_free_pages(ce50cbc0,d0807000,d0808000,a75,c4ccfb68) at 
> vm_hold_free_pages+0x142
> allocbuf(ce50cbc0,0,c043b873,74c,c449f5b4) at allocbuf+0x1b8
> getnewbuf(0,0,8000,8000,200) at getnewbuf+0x3fc
> getblk(c449f5b4,2878c80,0,8000,0) at getblk+0x38e
> breadn(c449f5b4,2878c80,0,8000,0) at breadn+0x52
> bread(c449f5b4,2878c80,0,8000,0) at bread+0x4c
> ffs_update(c4631db0,0,1,54,c0af9b88) at ffs_update+0x206
> ufs_inactive(d7077c30,d7077c4c,c02c1333,d7077c30,0) at ufs_inactive+0x1f5
> ufs_vnoperate(d7077c30,0,c043d141,8e3,c048efa0) at ufs_vnoperate+0x18
> vput(c4631db0,0,c044c2d9,3b2,c4631db0) at vput+0x143
> vm_pageout_scan(0,0,c044c2d9,5d5,1f4) at vm_pageout_scan+0x67d
> vm_pageout(0,d7077d48,c043313d,314,1a537318) at vm_pageout+0x2db
> fork_exit(c03a5fe0,0,d7077d48) at fork_exit+0xcf
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0x1, eip = 0, esp = 0xd7077d7c, ebp = 0 ---
> db>

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

Re: usb digital camera failure

[Doug White]

On Sun, 5 Oct 2003, Matt wrote:

> I have a fuji digital camera which has always previously worked with
> -current no problems. However I have not tried to copy images from it
> for a couple of months now.

[...]

> Oct  5 23:02:58 heather kernel: umass0: Fuji Photo Film USB Mass
> Storage, rev 1.10/10.00, addr 3
> Oct  5 23:02:59 heather kernel: GEOM: create disk da0 dp=0xc40abc50
> Oct  5 23:02:59 heather kernel: da0 at umass-sim0 bus 0 target 0 lun 0
> Oct  5 23:02:59 heather kernel: da0: 
> Removable Direct Access SCSI-0 device
> Oct  5 23:02:59 heather kernel: da0: 1.000MB/s transfers
> Oct  5 23:02:59 heather kernel: da0: 62MB (128000 512 byte sectors: 64H
> 32S/T 62C)

Which USB controller? There are known issues with the ohci driver at
current.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ACPI error msgs at boot

[Doug White]

On Sun, 5 Oct 2003, Matt Douhan wrote:

> Oct  5 23:40:58 dragonfruit kernel: ACPI-1287: *** Error: Method execution
> failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc47d
> d980), AE_AML_REGION_LIMIT
> Oct  5 23:40:58 dragonfruit kernel: ACPI-1287: *** Error: Method execution
> failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc47d
> d980), AE_AML_REGION_LIMIT
> Oct  5 23:40:58 dragonfruit kernel: ACPI-1287: *** Error: Method execution
> failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc47d
> d980), AE_AML_REGION_LIMIT

These are bugs in the AML on your system, trying to access memory that has
not been declared. Not sure FreeBSD can do anything about this directly.
This appears to be in the battery status method.

It is possible to export the AML to ASL, fix the defective region
declarations, and load a new table at boot.  Not for the faint of heart,
though.  What kind of laptop is this?

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: usb keyboard not working in single user mode

[Doug White]

On Fri, 3 Oct 2003, Ken McKittrick wrote:

> I've got 5.1-current running on an IBM BladeCenter HS20. This thing has
> a USB KVM built-in. It's working in multi-user mode. Problem is when I
> boot to single user, can't do anything.

Check that atkbd is using flags 0x1.  That should cause atkbd not to
attach and allow ukbd to take over.  If your system happens to emulate a
atkbd even when one is not attached, you will have to modify the start
scripts to run kbdcontrol even in the single-user case (if thats even
possible).

> I'm looking for a way to fire up the usbd in single user mode. So far
> I've tried:
>
> Loading usbd.ko, ugen.ko, ukbd.ko modules via loader.conf. NO GOOD,
> hangs the system.

A more recent -CURRENT should fix this issue for you.

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: GEOM BDE stats / questions about crypto transformations

[Donald Creel]

In message <[EMAIL PROTECTED]>, Mike Tancsa writes:

>However, overall the CPU is lower when running with the hifn 
>card defined in the kernel.  It makes a large difference in CPU usage when 
>scp'ing a file across using 3des.  Perhaps when the new Soekris card which 
>does AES comes out, these numbers will speed up.
>
>In the mean time is anyone using this in production ?  Are you using any 
>USB keys for the storing the pass phrase ?  If so, can you give me some 
>details as to how you set it up ?

I am using SmartMedia card with my Olympus Digital Camera to store a copy of the key 
made as per the handbook. The neat thing about it is it can have a totally different 
name from the original lock file, and can use either to attach.

Since I don't have USB key, I am assuming it will work if you mount it, copy the key 
to it and specify that path when attaching.



-- 
___
Get your free Verizonmail at www.verizonmail.com

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

ptmx, /dev/pts support for 5.x

[Robert Watson]

Last week, I did a bit of experimentation to look at privilege issues in
the allocation of ptys on FreeBSD.  Right now, to safely allocate a
pty/tty pair, you basically need privilege (otherwise you can't
chown/chmod the slave node).  I took a look at some of the approaches used
by other systems (specifically Linux, Solaris) and implemented basic ptmx
support for FreeBSD:

  http://www.watson.org/~robert/freebsd/pts/

I took the existing tty_pty.c driver code and remunged most of the dev_t
and clone handling, as well as open/close of both master and slave.  It's
far from perfect -- more of an experiment really, but it has some notable
benefits, including allowing programs like window, xterm, etc, to allocate
ptys safely without privilege (although utmp still requires privilege if
you're into that sort of thing).  pts/ttys are also GC'd to reset
ownership/permissions/flags in a race-free manner. 

The one bug I've been bumping my head against and haven't yet manage to
resolve is that controlling tty support appears to be broken -- perhaps a
property of the ordering of dev_t vs. tty initialization.

The one other caveat is that to allocate a new pty, it's sufficient to
lookup /dev/ptmx, not just open it, due to our devfs cloning approach.  I
probably need some timeout to talk along and GC allocated but unopened
ptys.

I include some lightweight implementations of openpty(), grantpt(), etc,
based on the kernel code.  Ideally, the libraries would support backward
compatibility, however, preferring ptmx/pts over pty/tty but supporting
kernels with either...

Thoughts, etc, welcome -- I probably don't have time to follow through
effectively on this for a few weeks, so if someone else wants to grab and
run with it (perhaps throwing out my implementation on the way), they
should feel free.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories

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

Re: D-Link DWL-520+

[tokza]

On Monday 06 October 2003 03:26, Marcos Biscaysaqu wrote:
> That wireless card has Texas Instrument chipset and doesn't work on
> freebsd, I have got a driver for linux but is very dodgy.
> I wont recomend you use this wireless card.
>

The only reason to talk about this card is  it's name, very similar to DWL-520 
which works perfect with freebsd (as mailing lists says). Only one little 
plus ("+") makes everything sucks :-)
Tomorrow I'll go to shop for moneyback...

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

ATAng primary-secondary drive oddness

[Barry Miller]

None of the previous posts on this seem to describe exactly what I'm
seeing:

5.1-REL always detects the secondary drive.
5.1-CUR never detects the secondary.
5.1-CUR + ata-lowlevel 1.11 detects it the FIRST time it's booted
immediately after 5.1-REL.  Always.  On subsequent boots, no luck.

A = 1st CUR + ata-lowlevel 1.11 after running REL.
B = 2nd and following boots of same.

B ata0-slave:  stat=0x10 err=0x01 lsb=0x00 msb=0x00
A ata0-slave:  stat=0x50 err=0x01 lsb=0x00 msb=0x00
A ata0: reset tp2 mask=03 stat0=50 stat1=50 devices=0x3
B ata0: reset tp2 mask=03 stat0=50 stat1=10 devices=0x1
A ata0-slave: pio=0x0c wdma=0x22 udma=0x45 cable=80pin
A ad1: setting UDMA100 on Intel ICH4 chip
A ad1:  ATA-6 disk at ata0-slave

I'll provide more info or try something different if it might help.

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

Re: D-Link DWL-520+

[Marcos Biscaysaqu]

That wireless card has Texas Instrument chipset and doesn't work on 
freebsd, I have got a driver for linux but is very dodgy.
I wont recomend you use this wireless card.

Brad Knowles wrote:

At 2:49 AM +0400 2003/10/06, tokza wrote:

 So far as I know, there are no open-source drivers for any 22mpbs
 card anywhere.


 Hm, what does "22 mbps" mean? As I know, DWL-520+ is a 
802.11b-standart based
 card and the max speed is 11mbps as mentioned in this standart.


In this case, there is only one vendor I know of that sells 
802.11b equipment that is also capable of handling 22mbps speeds. That 
would be TI, and USR is one of their major partners.  It is the TI 
chipset that I am talking about.

See 
. 

D-Link is also a reseller of TI chipset hardware.  See 
.

 
Reading card
 specification I thought that "22 mbps with AirPlus series" is a kind 
of PR or
 adverticement :-)
 Or is this a kind of "enhanced 802.b" standart? Where can I read 
smth about
 this?


See above.

--

Marcos Biscaysaqu

Systems Administrator
ThePacific.Net Ltd.


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

Re: D-Link DWL-520+

[Brad Knowles]

At 2:49 AM +0400 2003/10/06, tokza wrote:

So far as I know, there are no open-source drivers for any 22mpbs
 card anywhere.
 Hm, what does "22 mbps" mean? As I know, DWL-520+ is a 802.11b-standart based
 card and the max speed is 11mbps as mentioned in this standart.
	In this case, there is only one vendor I know of that sells 
802.11b equipment that is also capable of handling 22mbps speeds. 
That would be TI, and USR is one of their major partners.  It is the 
TI chipset that I am talking about.

	See 
.

	D-Link is also a reseller of TI chipset hardware.  See 
.

 Reading card
 specification I thought that "22 mbps with AirPlus series" is a kind of PR or
 adverticement :-)
 Or is this a kind of "enhanced 802.b" standart? Where can I read smth about
 this?
	See above.

--
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(+++)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: CDROM / UDMA problem on -current (2 hours old)

[Thomas Quinot]

Le 2003-10-05, Jan Stocker écrivait :

> it's an atapicam problem... 

That we do not know so far. Recent problems reported by ATAPI/CAM users
were mostly ATA and CAM bugs. Please do not make such hasty statements
until a complete analysis of the problem has been made.

Thanks,
Thomas.

-- 
[EMAIL PROTECTED]


pgp0.pgp
Description: PGP signature

Re: CDROM / UDMA problem on -current (2 hours old)

[Thomas Quinot]

Le 2003-10-05, Jan Stocker écrivait :

> /usr/local/bin/cdrecord: Permission denied. Cannot send SCSI cmd via ioctl

Check perms on your /dev nodes.

Thomas.

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

Re: CDROM / UDMA problem on -current (2 hours old)

[Thomas Quinot]

Le 2003-10-04, Jan Stocker écrivait :

> are printed so fast i cant really read  but it must be something
> like that:
> acd1: WARNING - REQUEST_UDMA  (error request)
> acd1: WARNING - INQUIRE_SENSE  (retrying request)

Little can be said without complete and accurate error messages,
preferrably including a complete kernel backtrace, but still it would be
interesting to know whether the enclosed patch changes anything to your
situation.

Thomas.

Index: ata-queue.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-queue.c,v
retrieving revision 1.6
diff -u -r1.6 ata-queue.c
--- ata-queue.c 19 Sep 2003 12:46:12 -  1.6
+++ ata-queue.c 5 Oct 2003 22:56:28 -
@@ -223,7 +223,7 @@
 
 /* if this is a UDMA CRC error, retry request */
 if (request->flags & ATA_R_DMA && request->error & ATA_E_ICRC) {
-   if (request->retries--) {
+   if (request->retries-- > 0) {
ata_prtdev(request->device,
   "WARNING - %s UDMA ICRC error (retrying request)\n",
   ata_cmd2str(request));
 
-- 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

X does not work ... [alc@FreeBSD.org: cvs commit: src/sys/vm device_pager.c]

[Alan Cox]

This should resolve the problem starting X.

- Forwarded message from Alan Cox <[EMAIL PROTECTED]> -

X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
From: Alan Cox <[EMAIL PROTECTED]>
Date: Sun, 5 Oct 2003 15:23:44 -0700 (PDT)
To: [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: cvs commit: src/sys/vm device_pager.c
X-FreeBSD-CVS-Branch: HEAD
Precedence: bulk
X-Loop: FreeBSD.ORG
X-Virus-Scanned: by amavis-20030314-p2 at cs.rice.edu
X-DCC--Metrics: cs.rice.edu 1067; Body=1 Fuz1=1 Fuz2=1

alc 2003/10/05 15:23:44 PDT

  FreeBSD src repository

  Modified files:
sys/vm   device_pager.c 
  Log:
  The addition of a locking assertion to vm_page_zero_invalid() has revealed
  a long-time bug: vm_pager_get_pages() assumes that m[reqpage] contains a
  valid page upon return from pgo_getpages().  In the case of the device
  pager this page has been freed and replaced by a fake page.  The fake page
  is properly inserted into the vm object but m[reqpage] is left pointing
  to a freed page.  For now, update m[reqpage] to point to the fake page.
  
  Submitted by:   tegge
  
  Revision  ChangesPath
  1.69  +1 -0  src/sys/vm/device_pager.c

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

Re: D-Link DWL-520+

[tokza]

On Monday 06 October 2003 02:11, Brad Knowles wrote:

>   So far as I know, there are no open-source drivers for any 22mpbs
> card anywhere. 

Hm, what does "22 mbps" mean? As I know, DWL-520+ is a 802.11b-standart based 
card and the max speed is 11mbps as mentioned in this standart. Reading card 
specification I thought that "22 mbps with AirPlus series" is a kind of PR or 
adverticement :-)
Or is this a kind of "enhanced 802.b" standart? Where can I read smth about 
this?

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

Re: D-Link DWL-520+

[Brad Knowles]

At 12:31 AM +0400 2003/10/06, tokza wrote:

 If it's not supported, I'm afraid there's no any 22mbps card supported by
 freebsd.
	So far as I know, there are no open-source drivers for any 22mpbs 
card anywhere.  A friend of mine does Linux driver development, in 
particular for wireless networking cards.  He's been trying to get 
specs for 22mbps cards for years, and everything from every vendor 
requires NDA, and the OEM manufacturer won't even talk to him.

	If you find any open-source drivers for any 22mbps cards under 
any OS, please let me know.

--
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(+++)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

usb digital camera failure

[Matt]

I have a fuji digital camera which has always previously worked with 
-current no problems. However I have not tried to copy images from it 
for a couple of months now.

I tried today with a -current world of:

FreeBSD heather.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Sep 
28 20:12:26 BST 2003 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/HEATHER  i386

and I get this happen. I plug the camera in and get this:

Oct  5 23:02:58 heather kernel: umass0: Fuji Photo Film USB Mass 
Storage, rev 1.10/10.00, addr 3
Oct  5 23:02:59 heather kernel: GEOM: create disk da0 dp=0xc40abc50
Oct  5 23:02:59 heather kernel: da0 at umass-sim0 bus 0 target 0 lun 0
Oct  5 23:02:59 heather kernel: da0:  
Removable Direct Access SCSI-0 device
Oct  5 23:02:59 heather kernel: da0: 1.000MB/s transfers
Oct  5 23:02:59 heather kernel: da0: 62MB (128000 512 byte sectors: 64H 
32S/T 62C)

I can mount_msdosfs /dev/da0s1 this device and see the filesystem. 
However when I try to cp *.jpg from it I get this:

Oct  5 23:03:49 heather kernel: umass0: CBI bulk-in stall clear failed, 
IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI bulk-out stall clear failed, 
IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI reset failed, IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI bulk-in stall clear failed, 
IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI bulk-out stall clear failed, 
IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI reset failed, IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI bulk-in stall clear failed, 
IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI bulk-out stall clear failed, 
IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI reset failed, IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI bulk-in stall clear failed, 
IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI bulk-out stall clear failed, 
IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI reset failed, IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI bulk-in stall clear failed, 
IOERROR
Oct  5 23:03:49 heather kernel: umass0: CBI bulk-out stall clear failed, 
IOERROR
Oct  5 23:03:49 heather kernel: vnode_pager_getpages: I/O read error
Oct  5 23:03:49 heather kernel: vm_fault: pager read error, pid 1179 (cp)

and the cp process reports this:

[EMAIL PROTECTED] 100_fuji]# ls
dscf0001.jpg dscf0006.jpg dscf0011.jpg dscf0016.jpg dscf0021.jpg
dscf0002.jpg dscf0007.jpg dscf0012.jpg dscf0017.jpg dscf0022.jpg
dscf0003.jpg dscf0008.jpg dscf0013.jpg dscf0018.jpg dscf0023.jpg
dscf0004.jpg dscf0009.jpg dscf0014.jpg dscf0019.jpg dscf0024.jpg
dscf0005.jpg dscf0010.jpg dscf0015.jpg dscf0020.jpg dscf0025.jpg
[EMAIL PROTECTED] 100_fuji]# cp * ~matt
cp: /home/matt/dscf0024.jpg: Bad address
cp: /home/matt/dscf0023.jpg: Bad address
cp: /home/matt/dscf0022.jpg: Bad address
... plus all the rest of the files ...

So what's wrong?

This used to work with -current from around a month ago. I've not tried 
it since until now however.

Matt.

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

ACPI error msgs at boot

[Matt Douhan]

Hello

I get the following error msgs on the following system

11:53pm mdouhan @ [dragonfruit] ~ > uname -a
FreeBSD dragonfruit.fruitsalad.org 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Sun Oct  
5 23:21:41 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/
sys/DRAGONFRUIT  i386
11:54pm mdouhan @ [dragonfruit] ~ >

Oct  5 23:40:58 dragonfruit kernel: ACPI-1287: *** Error: Method execution 
failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc47d
d980), AE_AML_REGION_LIMIT
Oct  5 23:40:58 dragonfruit kernel: ACPI-1287: *** Error: Method execution 
failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc47d
d980), AE_AML_REGION_LIMIT
Oct  5 23:40:58 dragonfruit kernel: ACPI-1287: *** Error: Method execution 
failed [\_SB_.PCI0.LPCB.BAT1._BST] (Node 0xc47d
d980), AE_AML_REGION_LIMIT

rgds

Matt

-- 
Matt Douhan
www.fruitsalad.org
[EMAIL PROTECTED]
ping elvis
elvis is alive


pgp0.pgp
Description: signature

errors on boot

[Matt Douhan]

I get the following erros on boot.

11:41pm mdouhan @ [dragonfruit] ~ > uname -a
FreeBSD dragonfruit.fruitsalad.org 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Sun Oct  
5 23:21:41 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/
sys/DRAGONFRUIT  i386
11:44pm mdouhan @ [dragonfruit] ~ >




-- 
Matt DouhanOct  5 23:40:58 dragonfruit kernel: sysctl_old_user() with the 
following non-sleepable locks held:
Oct  5 23:40:58 dragonfruit kernel: exclusive sleep mutex kernel linker r = 0 
(0xc07955e0) locked @ /usr/src/sys/kern/kern
_linker.c:1800
Oct  5 23:40:58 dragonfruit kernel: sysctl_old_user() with the following 
non-sleepable locks held:
Oct  5 23:40:58 dragonfruit kernel: exclusive sleep mutex kernel linker r = 0 
(0xc07955e0) locked @ /usr/src/sys/kern/kern
_linker.c:1800
Oct  5 23:40:58 dragonfruit kernel: sysctl_old_user() with the following 
non-sleepable locks held:
Oct  5 23:40:58 dragonfruit kernel: exclusive sleep mutex kernel linker r = 0 
(0xc07955e0) locked @ /usr/src/sys/kern/kern
_linker.c:1800
Oct  5 23:40:58 dragonfruit kernel: sysctl_old_user() with the following 
non-sleepable locks held:
Oct  5 23:40:58 dragonfruit kernel: exclusive sleep mutex kernel linker r = 0 
(0xc07955e0) locked @ /usr/src/sys/kern/kern

Regards

Matt

www.fruitsalad.org
[EMAIL PROTECTED]
ping elvis
elvis is alive


pgp0.pgp
Description: signature

D-Link DWL-520+

[tokza]

Hello, 
Does anybody know about $subj PCI wirelerss card. I read mail-archive and 
found that this card does not equal dwl-520 which has prism2.5 chipset and 
works well with wi driver. $subj was not supported few months ago, so what's 
now?
If it's not supported, I'm afraid there's no any 22mbps card supported by 
freebsd.

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

D-Link DWL-520+

[tokza]

Hello, 
Does anybody know about $subj PCI wirelerss card. I read mail-archive and 
found that this card does not equal dwl-520 which has prism2.5 chipset and 
works well with wi driver. $subj was not supported few months ago, so what's 
now?
If it's not supported, I'm afraid there's no any 22mbps card supported by 
freebsd.

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

Re: Nvidia driver

[Mike Hunter]

On Oct 03, "Daniel O'Connor" wrote:

> On Friday 03 October 2003 16:34, Mike Hunter wrote:
> > How do you turn those down?  /boot/loader.conf?  I tried saying
> > "hw.nvidia.card.rates="2x 1x" but that didn't seem to do anything (I have
> > a feeling that putting that in /boot/loader.conf makes no sense...please
> > consider this a desperate cry for help.)
> 
> Hmm, I am trying to remember :)
> Ahh!
> Here is a fragment of my loader.conf..
> nvidia_load="YES"
> machdep.disable_mtrrs="1"
> hw.nvidia.registry.ReqAGPRate="1"

Woot!  This fixed it.  Thank you!

This also has allowed me to drive an external monitor properly.

Thanks again,

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

Re: X does not work on todays current with ATI

[Marius Strobl]

On Sun, Oct 05, 2003 at 04:56:53PM +0200, Matt Douhan wrote:
> Hello
> 
> I am unable to start X with a current as of today 08.00 CEST, it crashes to
> the debugger with a fatal trap 12, I poked around to see if anything useful
> was in the logs but I could not find anything, can you please advice what
> log I could send to aid in hunting down this problem?
> 

"Me, too"

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: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address   = 0x1c
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc0503499
stack pointer   = 0x10:0xdc91ab9c
frame pointer   = 0x10:0xdc91abb8
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 = 582 (XFree86)
panic: from debugger
cpuid = 0; lapic.id = 0100
boot() called on cpu#0
Uptime: 28m17s
Dumping 512 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
---
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc050c3a3 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2  0xc050c788 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3  0xc043eff2 in db_panic () at /usr/src/sys/ddb/db_command.c:450
#4  0xc043ef6a in db_command (last_cmdp=0xc06d8e00, cmd_table=0x0, 
aux_cmd_tablep=0xc0693a6c, aux_cmd_tablep_end=0xc0693a70)
at /usr/src/sys/ddb/db_command.c:346
#5  0xc043f078 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6  0xc0441db9 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7  0xc0623143 in kdb_trap (type=12, code=0, regs=0xdc91ab5c)
at /usr/src/sys/i386/i386/db_interface.c:171
#8  0xc063bb96 in trap_fatal (frame=0xdc91ab5c, eva=0)
at /usr/src/sys/i386/i386/trap.c:814
at /usr/src/sys/ddb/db_command.c:346
#5  0xc043f078 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#6  0xc0441db9 in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:73
#7  0xc0623143 in kdb_trap (type=12, code=0, regs=0xdc91ab5c)
at /usr/src/sys/i386/i386/db_interface.c:171
#8  0xc063bb96 in trap_fatal (frame=0xdc91ab5c, eva=0)
at /usr/src/sys/i386/i386/trap.c:814
#9  0xc063b881 in trap_pfault (frame=0xdc91ab5c, usermode=0, eva=28)
at /usr/src/sys/i386/i386/trap.c:733
#10 0xc063b453 in trap (frame=
  {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1066886654, tf_esi = 1645, tf_ebp 
= -594433096, tf_isp = -594433144, tf_ebx = 0, tf_edx = 0, tf_ecx = 1, tf_eax = 0, 
tf_trapno = 12, tf_err = 0, tf_eip = -1068485479, tf_cs = 8, tf_eflags = 66118, tf_esp 
= 1, tf_ss = -997343232}) at /usr/src/sys/i386/i386/trap.c:418
#11 0xc0624a48 in calltrap () at {standard input}:103
#12 0xc05fb35e in vm_page_zero_invalid (m=0x66d, setvalid=1)
at /usr/src/sys/vm/vm_page.c:1645
---Type  to continue, or q  to quit--- 
#13 0xc05ebca2 in vm_fault (map=0xc19216e4, vaddr=674037760, 
fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_pager.h:131
#14 0xc063b7b6 in trap_pfault (frame=0xdc91ad48, usermode=1, eva=674041472)
at /usr/src/sys/i386/i386/trap.c:709
#15 0xc063b364 in trap (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077937450, tf_esi = 674041472, 
tf_ebp = -1077937480, tf_isp = -594432652, tf_ebx = 674037760, tf_edx = 2, tf_ecx = 2, 
tf_eax = -1077937450, tf_trapno = 12, tf_err = 4, tf_eip = 673893577, tf_cs = 31, 
tf_eflags = 66050, tf_esp = -1077937532, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:317
#16 0xc0624a48 in calltrap () at {standard input}:103
---Can't read userspace from dump, or kernel process---

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

msdosfs mask?

[Nate Lawson]

In the past, msdosfs has taken its permissions from the mountpoint.
Recently I noticed that this still works for files in the root directory
but subdirectories are all chmod 000.  Has anyone else seen this?  Adding
the -m=755 flag for instance does work for the files in the top of the
mountpoint (i.e. command.com) but not subdirectories, which are still 000.
What's going on?

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

Re: mounting vfat at boot

[Bruce M Simpson]

On Sun, Oct 05, 2003 at 06:20:45PM +0200, Christer Solskogen wrote:
> /dev/ad1s1  /mnt/dmsdos   rw  -m 775,user
> /dev/ad0s2  /mnt/emsdos   rw, -m 775,user
^
This should be msdosfs.

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

Re: mounting vfat at boot

[Simon L. Nielsen]

On 2003.10.05 18:20:45 +0200, Christer Solskogen wrote:
> FreeBSD 5.1-RELEASE
> 
> I got the following lines in my /etc/fstab :
> 
> /dev/ad1s1  /mnt/dmsdos   rw  -m 775,user
> /dev/ad0s2  /mnt/emsdos   rw, -m 775,user

I think it should be msdosfs on -CURRENT.

-- 
Simon L. Nielsen
FreeBSD Documentation Team


pgp0.pgp
Description: PGP signature

mounting vfat at boot

[Christer Solskogen]

FreeBSD 5.1-RELEASE

I got the following lines in my /etc/fstab :

/dev/ad1s1  /mnt/dmsdos   rw  -m 775,user
/dev/ad0s2  /mnt/emsdos   rw, -m 775,user

And everytime i reboot(dual system) it stops when doing a fsck.

fsck: exec /usr/sbin/fsck_msdos for /dev/ad1s1: No such file or
directory 
fsck: exec /usr/sbin/fsck_msdos for /dev/ad0s2: No such file or
directory

(it makes the system go into non-network mode, with just root.)
if i 'exit' that, the system boots nicely(it even MOUNTS my vfat
drivers)

it seems just like it cant fsck my disks(i dont want it to, either)


-- 
Med Vennlig Hilsen / Best regards
Christer Solskogen
http://carebears.mine.nu/~solskogen


When you're up to your nose in shit,
be sure to keep your mouth shut.

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

LOR in schedcpu(), sched_4bsd.c

[Bruce M Simpson]

With today's CURRENT:

...
GEOM: create disk ad0 dp=0xc2a3a380
ad0: 38166MB  [77545/16/63] at ata0-master UDMA100
acd0: DVDROM <_NEC DV-5700B> at ata1-master UDMA33
Mounting root from ufs:/dev/ad0s1a
Loading configuration files.
Entropy harvesting: interrupts ethernet point_to_point.
Reseed type 1
Reseed finish
lock order reversal
 1st 0xc06bfa20 callout_dont_sleep (callout_dont_sleep) @ kern/kern_timeout.c:223
 2nd 0xc06bed80 allproc /sched_4bsd.c:253
Stack backtrace:
backtrace(c06537e4,c06bed80,c065018e,c065018e,c0651c30) at backtrace+0x17
witness_lock(c06bed80,0,c0651c30,fd,c06c1e60) at witness_lock+0x697
_sx_slock(c06bed80,c0651c27,fd,8,c0651945) at _sx_slock+0xa9
schedcpu(0,0,c065193c,df,c12a8ab0) at schedcpu+0x3f
softclock(0,0,c064e447,230,c12a77d0) at softclock+0x1fb
ithread_loop(c129d200,cdb17d48,c064e2c1,314,c7e8) at ithread_loop+0x182
fork_exit(c04aa4a0,c129d200,cdb17d48) at fork_exit+0xc1
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xcdb17d7c, ebp = 0 ---
Debugger("witness_lock")
Stopped at  Debugger+0x54:  xchgl   %ebx,in_Debugger.0
db> show locks
exclusive sleep mutex callout_dont_sleep r = 0 (0xc06bfa20) locked @ 
kern/kern_timeout.c:223
db> show witness
Sleep locks:
0 taskqueue kthread -- last acquired @ kern/subr_taskqueue.c:253
0 g_xdown -- last acquired @ geom/geom_io.c:351
1  ATA disk bioqueue lock -- last acquired @ dev/ata/ata-disk.c:240
3  bio queue -- last acquired @ geom/geom_io.c:64
5  Malloc Stats -- last acquired @ kern/kern_malloc.c:335
3  ATA queue lock -- last acquired @ dev/ata/ata-queue.c:174
8  UMA pcpu -- last acquired @ vm/uma_core.c:1726
9   KMAP ENTRY -- last acquired @ vm/uma_core.c:1744
9   UMA zone -- last acquired @ vm/uma_core.c:1744
0 g_xup -- last acquired @ geom/geom_io.c:370
2  Giant -- last acquired @ kern/kern_timeout.c:216
3   malloc -- last acquired @ cquired @ kern/subr_eventhandler.c:213
4eventhandler list -- last acquired @ kern/kern_exit.c:210
3   vm object_list -- last acquired @ vm/vm_object.c:620
3   arc4_mtx -- last acquired @ libkern/arc4random.c:137
3   UMA lock -- last acquired @ vm/uma_core.c:802
3   filedesc structure -- last acquired @ kern/kern_descrip.c:1625
4pipe mutex -- last acquired @ kern/sys_pipe.c:481
5 sigio lock -- last acquired @ kern/kern_descrip.c:587
6  process group -- last acquired @ kern/kern_fork.c:575
7   process lock -- last acquired @ kern/kern_prot.c:1821
8struct pargs.ref -- last acquired @ kern/kern_proc.c:1077
8sigacts -- last acquired @ kern/kern_sig.c:596
8vnode interlock -- last acquired @ kern/vfs_subr.c:2176
9 Syncer mtx -- last acquired @ kern/vfs_subr.c:1663
9 vnode_free_list -- last acquired @ kern/vfs_subr.c:923
9 spechash -- last acquired @ kern/vfs_subr.c:1989
8ktrace -- last acquired @ kern/kern_fork.c:601
8session -- last acquired @ kern/kern_fork.c:584
9 uidinfo hash -- last acquired @ kern/kern_resource.c:878
10 sleep mtxpool -- last acquired @ kern/kern_prot.c:1685
10 uidinfo struct -- last acquired @ order list:0
11  allprison -- last acquired @ order list:0
3   ithread -- last acquired @ kern/kern_intr.c:265
3   GEOM orphanage -- last acquired @ geom/geom_event.c:169
3   rman head -- last acquired @ kern/subr_rman.c:110
3   sf_bufs list lock -- last acquired @ i386/i386/vm_machdep.c:577
5Malloc Stats -- (already displayed)
5system map -- last acquired @ vm/vm_map.c:2904
6 kmem object -- last acquired @ vm/vm_kern.c:437
7  vm page queue mutex -- last acquired @ vm/vm_object.c:594
8   vnode interlock -- (already displayed)
8   UMA pcpu -- (already displayed)
7  CMAPCADDR12 -- last acquired @ i386/i386/pmap.c:2475
6 vm object -- last acquired @ vm/vm_object.c:433
7  vm page queue mutex -- (already displayed)
7  CMAPCADDR12 -- (already displayed)
3   taskqueue list -- last acquired @ kern/subr_taskqueue.c:384
3   kernel linker -- last acquire/kern_linker.c:460
3   rman -- last acquired @ kern/subr_rman.c:132
5Malloc Stats -- (already displayed)
5system map -- (already displayed)
3   sellck -- last acquired @ kern/sys_generic.c:1174
3   domain list -- last acquired @ kern/uipc_domain.c:114
3   devd -- last acquired @ kern/subr_bus.c:406
3   callout_dont_sleep -- last acquired @ kern/kern_timeout.c:223
4ifnet -- last acquired @ net/if.c:1172
4tcp -- last acquired @ netinet/tcp_timer.c:141
4ipflow list head -- last acquired @ netinet/ip_flow.c:288
4ipqlock -- last acquired @ netinet/ip_input.c:1237
4mbuf PCPU list lock -- last acquired @ kern/subr_mbuf.c:926
5 mbuf subsystem general lists lock -- last acquired @ kern/subr_mbuf.c:676
3   vm86 lock -- last acquired @ i386/i386/vm86.c:606
3   ATA queue lock -- (already displayed)
3   mntvnode vfs_subr.c:1054
3   pseudofs -- last acquired @ fs/pseudofs/pseudofs_fileno.c:86
3   bpf global lock -- last acquired @ net/bpf.c:1383
3   IPFW static r

panic in rman_reserve_resource_bound

[Bruce M Simpson]

With today's -CURRENT:

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...   
/boot/kernel/acpi.ko text=0x3abd4 data=0x16f8+0xe68 syms=[0x4+0x5c10+0x4+0x7a31]
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.1-CURRENT #0: Sun Oct  5 16:11:39 BST 2003
[EMAIL PROTECTED]:/usr/home/bms/cvs/src/sys/i386/compile/KIMCHI_DEBUG
Preloaded elf kernel "/boot/kernel/kernel" at 0xc082a000.
Preloaded elf module "/boot/kernel/vesa.ko" at 0xc082a1cc.
Preloaded elf module "/boot/kernel/if_vr.ko" at 0xc082a278.
Preloaded elf module "/boot/kernel/usb.ko" at 0xc082a324.
Preloaded elf module "/boot/kernel/netgraph.ko" at 0xc082a3cc.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc082a47c.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Athlon(tm) processor (1435.75-MHz 686-class CPU)
  Origin = "AuthenticAMD"  Id = 0x642  Stepping = 2
  
Features=0x183f9ff
  AMD Features=0xc044
real memory  = 268369920 (255 MB)
avail memory = 251154432 (239 MB)
Pentium Pro MTRR support enabled
VESA: v3.0, 4096k memory, flags:0x1, mode table:0xc0799d22 (122)
VESA: NVidia
npx0: [FAST]
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 8 entries at 0xc00fdee0
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
acpi_cpu0:  on acpi0
acpi_button0:  on acpi0
acpi_button1:  on acpi0
pcib0:  port 
0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib0: slot 9 INTA is routed to irq 10
pcib0: slot 10 INTA is routed to irq 12
pcib0: slot 12 INTA is routed to irq 11
pcib0: slot 14 INTA is routed to irq 11
pcib0: slot 17 INTD is routed to irq 5
pcib0: slot 17 INTD is routed to irq 5
pcib0: slot 18 INTA is routed to irq 11
agp0:  mem 0xd000-0xd7ff at device 0.0 on pci0

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x181
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc04dfa55
stack pointer   = 0x10:0xc0c21834
frame pointer   = 0x10:0xc0c21878
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 = 0 (swapper)
kernel: type 12 trap, code=0
Stopped at  rman_reserve_resource_bound+0x3d5:  movl%ecx,0x4(%eax)
db> trace
rman_reserve_resource_bound(c071c1c0,d000,d7ff,800,0) at 
rman_reserve_resource_bound+0x3d5
rman_reserve_resource(c071c1c0,d000,d7ff,800,0) at 
rman_reserve_resource+0x3c
nexus_alloc_resource(c16a5480,c2d29380,3,c0c21ae8,d000) at 
nexus_alloc_resource+0xed
resource_list_alloc(c2d2930c,c16a6a80,c2d29380,3,c0c21ae8) at resource_list_alloc+0xdf
acpi_alloc_resource(c16a6a80,c2d29380,3,c0c21ae8,d000) at acpi_alloc_resource+0x54
bus_generic_alloc_resource(c16a6480,c2d29380,3,c0c21ae8,d000) at 
bus_generic_alloc_resource+0xaf
resource_list_alloc(c2d29304,c2d29400,c2d29380,3,c0c21ae8) at resource_list_alloc+0x1e4
pci_alloc_resource(c2d29400,c2d29380,3,c0c21ae8,0) at pci_alloc_resource+0x220
bus_alloc_resource(c2d29380,3,c0c21ae8,0,) at bus_alloc_resource+0xb2
agp_generic_attach(c2d29380,c0c21b24,c04d5349,c2d29400,c2d29380) at 
agp_generic_attach+0x53
agp_via_attach(c2d29380,c2ce3098,c0675adc,c07fa845,6) at agp_via_attach+0x22
device_probe_and_attach(c2d29380,0,c0c21b98,c080c0ea,c2d29400) at device_probe_an+0xb0
bus_generic_attach(c2d29400,c169f700,1,c080bea0,c2d29400) at bus_generic_attach+0x28
acpi_pci_attach(c2d29400,c2cf8098,c0675adc,612e7768,2e697063) at acpi_pci_attach+0xda
device_probe_and_attach(c2d29400,c2d2ef40,c0c21bfc,c080c1cf,c16a6480) at 
device_probe_and_attach+0xb0
bus_generic_attach(c16a6480,c2d2ef50,0,c169f700,c2d2ef40) at bus_generic_attach+0x28
acpi_pcib_attach(c16a6480,c2d2ef50,0,c0c21c34,c04d5349) at acpi_pcib_attach+0xcf
acpi_pcib_acpi_attach(c16a6480,c2d18098,c0675adc,c07fa845,c16a6580) at 
acpi_pcib_acpi_attach+0x1ed
device_probe_and_attach(c16a6480,4,c0c21ca0,c0806294,c16a6a80) at 
device_probe_and_attach+0xb0
bus_generic_attach(c16a6a80,c1693720,64,c08062b0,c16a6a80) at bus_generic_attach+0x28
acpi_probe_children(c16a6a80,c0807ab0,c16a6a00,0,1a4) at acpi_probe_children+0x94
acpi_attach(c16a6a80,c2d04098,c0675adc,c0819528,c2cf7050) at acpi_attach+0x6ee
device_probe_and_attach(c16a6a80,c16a5480,c0c21d2c,c0612bbc,c16a5480) at 
device_probe_and_attach+0xb0
bus_generic_attach(c16a5480,c16a5480,c0c21d5c,c04d5fe0,c16a5480) at 
bus_generic_attach+0x28
nexus_attach(c16a5480,c2cb6098,c0675adc,c066d1ae,0) at nexus_attach+0x1c
device_probe_and_attach(c16a5480,c168fe78,c0c21d80,c06044c5,c16a5a00) at 
device_probe_and

X does not work on todays current with ATI

[Matt Douhan]

Hello

I am unable to start X with a current as of today 08.00 CEST, it crashes to
the debugger with a fatal trap 12, I poked around to see if anything useful
was in the logs but I could not find anything, can you please advice what
log I could send to aid in hunting down this problem?

I do not have a serial console since this is my laptop so I cannot get
access to the debugger output in a simple way

I have a ATI Radeon Mobility 7500 on a ACER travelmate 420, cvsup and
rebuilt workld/kernel today and portupgrade -aurPR

rgds

Matt

Matt Douhan
Manager IT & Logistics
Hasta AB, Sweden
e-mail:[EMAIL PROTECTED]
www: www.hasta.se

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

Re: panic: pmap_enter: pte vanished, va: 0xbfbff000

[Bob Willcox]

On Sat, Oct 04, 2003 at 06:12:03PM +0200, Christian Brueffer wrote:
> Hi,
> 
> just got this panic on my smp box.  Sources are from October 2nd, around
> 9pm CEST.  A dump is available for further debugging.

I'm seeing this on one of my systems as well that I just recently updated
(Oct 4th). Mine will run for several hours prior to panicing.

Bob

> 
> 
> GNU gdb 5.3 (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-portbld-freebsd5.1"...
> panic: pmap_enter: pte vanished, va: 0xbfbff000
> panic messages:
> ---
> panic: pmap_enter: pte vanished, va: 0xbfbff000
> cpuid = 1; lapic.id = 0100
> boot() called on cpu#1
> 
> syncing disks, buffers remaining... 3842 3842 3842 3839 3839 3839 3839 3839 3842 
> 3838 3838 3838 3838 3838 38
> 38 3838 3838 3838 3838 3838 3838 3838 3838 3838 3838 3838 3838 3838 3838 
> giving up on 3553 buffers
> Uptime: 1d7h23m22s
> Dumping 511 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 4
>  64 480 496
>  ---
> #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
>240 dumping++;
>(kgdb) where
> #0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
> #1  0xc0514fb0 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
> #2  0xc05153b6 in panic (fmt=0xc06cb072 "pmap_enter: pte vanished, va: 0x%x")
>  at /usr/src/sys/kern/kern_shutdown.c:550
> #3  0xc06723dd in pmap_enter (pmap=0xc515fc80, va=3217027072, m=0xc17ce6e0, prot=5 
> '\005', wired=0)
>  at /usr/src/sys/i386/i386/pmap.c:1962
> #4  0xc062149c in vm_fault (map=0xc515fbd0, vaddr=3217027072, fault_type=1 '\001', 
> fault_flags=0)
>  at /usr/src/sys/vm/vm_fault.c:890
> #5  0xc0675e39 in trap_pfault (frame=0xdbc8dd48, usermode=1, eva=3217029420)
>  at /usr/src/sys/i386/i386/trap.c:709
> #6  0xc06759d4 in trap (frame=
>   {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 76, tf_esi = 134629896, tf_ebp = 
> -1077937832, tf_isp = -
>  607593100, tf_ebx = 51, tf_edx = 1, tf_ecx = 19, tf_eax = 0, tf_trapno = 12, tf_err 
> = 4, tf_eip = 673303409,
> tf_cs = 31, tf_eflags = 66118, tf_esp = -1077937876, tf_ss = 47}) at 
> /usr/src/sys/i386/i386/trap.c:317
> 
> 
> 
> - Christian
> 
> -- 
> Christian Brueffer[EMAIL PROTECTED]   [EMAIL PROTECTED]
> GPG Key:   http://people.freebsd.org/~brueffer/brueffer.key.asc
> GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D



-- 
Bob WillcoxGive a small boy a hammer and he will find
[EMAIL PROTECTED] that everything he encounters needs pounding.
Austin, TX
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Is pci a must on sparc64?

[Seigo Tanimura]

A sparc64 kernel without pci device fails to build.  The kernel is
configured for Ultra2 with no pci devices.

--- v --- log --- v ---
daiba% make
cc -c -O -pipe -g  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -g -nostdinc -I-  -I. -I../../.. -I../../../contrib/dev/acpica 
-I../../../contrib/ipfilter -I../../../contrib/dev/ath 
-I../../../contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common 
-finline-limit=15000 -fno-strict-aliasing  -mcmodel=medlow -msoft-float -ffreestanding 
-Werror  ../../../sparc64/sparc64/ofw_machdep.c
In file included from ../../../sparc64/sparc64/ofw_machdep.c:45:
../../../sparc64/pci/ofw_pci.h:41:24: ofw_pci_if.h: No such file or directory
*** Error code 1

Stop in /home/silver4/tanimura/p4-freefall/handoffpri/sparc64/compile/DAIBA.
daiba%
--- ^ --- log --- ^ ---

ofw_machdep.c unconditionally includes ofw_pci_if.h, even if pci
device is not configured.  Do I have to configure pci even for non-pci
machines?

-- 
Seigo Tanimura <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ls -c / ls -u doesn't work anymore

[Jan Stocker]

On Sun, 2003-10-05 at 12:11, Bruce Evans wrote:
> On Sun, 5 Oct 2003, Jan Stocker wrote:
> 
> > Newest world/kernel same prob
> >
> > [EMAIL PROTECTED]:~ # mkdir x
> > [EMAIL PROTECTED]:~ # cd x
> > [EMAIL PROTECTED]:~/x # touch b-first; sleep 60
> > [EMAIL PROTECTED]:~/x # touch c-second; sleep 60
> > [EMAIL PROTECTED]:~/x # touch a-third
> > [EMAIL PROTECTED]:~/x # ls -l -c
> > total 0
> > -rw-r--r--  1 jstocker  jstocker  0  5 Oct 11:10 a-third
> > -rw-r--r--  1 jstocker  jstocker  0  5 Oct 11:08 b-first
> > -rw-r--r--  1 jstocker  jstocker  0  5 Oct 11:09 c-second
> >
> >
> > looks very alphabetic
> 
> -c and -u only work when combined with -t.  This may be bogus, but it
> is no different than in 4.4BSD-Lite2 and it is specified by POSIX
> (POSIX.1-200x-draft7:
> 
> 21836 -cUse time of last modification of the file status 
> information (see  in the
> 21837   System Interfaces volume of IEEE Std 
> 1003.1-200x) instead of last modification of
> 21838   the file itself for sorting (-t) or writing (-l).
> 21864 -uUse time of last access (see  in the 
> System Interfaces volume of
> 21865   IEEE Std 1003.1-200x) instead of last 
> modification of the file for sorting (-t) or
> 21866   writing (-l).
> 
> The FreeBSD ls clearly attempts to implement this.   The FreeBSD man page
> is clearly a fuzzy version of this:
> 
>  -c  Use time when file status was last changed for sorting or print-
>  ing.
>  -u  Use time of last access, instead of last modification of the file
>  for sorting (-t) or printing (-l).
> 
> The FreeBSD man page is missing the critical detail that the status change
> time and access times are used _instead_ of the modification time.

and then -t sorts that date... okay works fine 

Jan



P.S.
but the behaviour has changed and i've nowhere read it. my old box:

FreeBSD  4.7-RC FreeBSD 4.7-RC #0: Thu Sep 19 01:04:45 MEST 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/  i386

has a  "ls -c" and does not need "ls -t -c". 

Jan



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

Re: cannot build kernel

[Matt Douhan]

On Sunday 05 October 2003 12.37, Bruce M Simpson wrote:
> On Sun, Oct 05, 2003 at 12:03:33PM +0200, Matt Douhan wrote:
> Content-Description: signed data
>
> > cvsup this morning 5th oct 12.05 PM
>
> Specify timezone please - I committed a fix for this a few hours ago.

CET as in Central European Time, I just saw the change come in using cvsup 
again, so I will rebuild and try it out.

-- 
Matt Douhan
www.fruitsalad.org
[EMAIL PROTECTED]
ping elvis
elvis is alive


pgp0.pgp
Description: signature

Re: cannot build kernel

[Bruce M Simpson]

On Sun, Oct 05, 2003 at 12:03:33PM +0200, Matt Douhan wrote:
Content-Description: signed data
> cvsup this morning 5th oct 12.05 PM

Specify timezone please - I committed a fix for this a few hours ago.

BMS


pgp0.pgp
Description: PGP signature

Re: ls -c / ls -u doesn't work anymore

[Bruce Evans]

On Sun, 5 Oct 2003, Jan Stocker wrote:

> Newest world/kernel same prob
>
> [EMAIL PROTECTED]:~ # mkdir x
> [EMAIL PROTECTED]:~ # cd x
> [EMAIL PROTECTED]:~/x # touch b-first; sleep 60
> [EMAIL PROTECTED]:~/x # touch c-second; sleep 60
> [EMAIL PROTECTED]:~/x # touch a-third
> [EMAIL PROTECTED]:~/x # ls -l -c
> total 0
> -rw-r--r--  1 jstocker  jstocker  0  5 Oct 11:10 a-third
> -rw-r--r--  1 jstocker  jstocker  0  5 Oct 11:08 b-first
> -rw-r--r--  1 jstocker  jstocker  0  5 Oct 11:09 c-second
>
>
> looks very alphabetic

-c and -u only work when combined with -t.  This may be bogus, but it
is no different than in 4.4BSD-Lite2 and it is specified by POSIX
(POSIX.1-200x-draft7:

21836 -cUse time of last modification of the file status 
information (see  in the
21837   System Interfaces volume of IEEE Std 1003.1-200x) 
instead of last modification of
21838   the file itself for sorting (-t) or writing (-l).
21864 -uUse time of last access (see  in the 
System Interfaces volume of
21865   IEEE Std 1003.1-200x) instead of last modification 
of the file for sorting (-t) or
21866   writing (-l).

The FreeBSD ls clearly attempts to implement this.   The FreeBSD man page
is clearly a fuzzy version of this:

 -c  Use time when file status was last changed for sorting or print-
 ing.
 -u  Use time of last access, instead of last modification of the file
 for sorting (-t) or printing (-l).

The FreeBSD man page is missing the critical detail that the status change
time and access times are used _instead_ of the modification time.

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

ATAng problem: harddisk not detected

[Stefan Ehmann]

After yesterday's cvsup and kernel/world build my primary slave harddisk
not longer gets detected (once again).

If I revert to src/sys/dev/ata/ata-lowlevel.c 1.11 it is detected
properly. (It might also work with later versions. If you need the exact
revision where it stopped working please tell me)

verbose dmesg can be found here
http://stud4.tuwien.ac.at/~e0125637/dmesg.new

verbose dmesg with ata-lowlevel.c 1.11
http://stud4.tuwien.ac.at/~e0125637/dmesg.old

Stefan Ehmann

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

cannot build kernel

[Matt Douhan]

cvsup this morning 5th oct 12.05 PM

I get the following error during buildkernel


cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/src/
sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/
src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL 
-include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding 
-Werror  /usr/src/sys/dev/usb/usb.c
/usr/src/sys/dev/usb/usb.c: In function `usbioctl':
/usr/src/sys/dev/usb/usb.c:555: warning: assignment from incompatible pointer 
type
*** Error code 1

Stop in /usr/obj/usr/src/sys/DRAGONFRUIT.
*** Error code 1

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

Stop in /usr/src.

-- 
Matt Douhan
www.fruitsalad.org
[EMAIL PROTECTED]
ping elvis
elvis is alive


pgp0.pgp
Description: signature

Re: CDROM / UDMA problem on -current (2 hours old)

[Jan Stocker]

> It seems Jan Stocker wrote:
That seems right :)
> > I've updates my -current system from Sep, 14th to todays -current (2
> > hours old). Now i cant boot further than detecting cdrom drives. After
> > testing my second cdrom (cdrw) for its UDMA capabilities the kernel
> > hangs in an endless loop. The output is a repeat from two lines which
> > are printed so fast i cant really read  but it must be something
> > like that:
> > 
> > acd1: WARNING - REQUEST_UDMA  (error request)
> > acd1: WARNING - INQUIRE_SENSE  (retrying request)
> > 
> > The drive is an 2x2x24x CD/RW from Traxdata which is detected previously
> > as:
> > 
> > acd1: CDRW  at ata1-slave WDMA2
> 
> Try a kernel without atapicam ?

Yep...
it's an atapicam problem... 

Thomas: Thats the same drive previously does produce the output in
cdrecord:

/usr/local/bin/cdrecord: Warning: controller returns zero sized Ricoh Vendor Page page.
/usr/local/bin/cdrecord: Warning: controller returns wrong size for Ricoh Vendor Page 
page.
/usr/local/bin/cdrecord: Warning: controller returns wrong page 0 for Ricoh Vendor 
Page page (30).
/usr/local/bin/cdrecord: Permission denied. Cannot send SCSI cmd via ioctl


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

Re: ls -c / ls -u doesn't work anymore

[Jan Stocker]

Newest world/kernel same prob

[EMAIL PROTECTED]:~ # mkdir x
[EMAIL PROTECTED]:~ # cd x
[EMAIL PROTECTED]:~/x # touch b-first; sleep 60
[EMAIL PROTECTED]:~/x # touch c-second; sleep 60
[EMAIL PROTECTED]:~/x # touch a-third
[EMAIL PROTECTED]:~/x # ls -l -c
total 0
-rw-r--r--  1 jstocker  jstocker  0  5 Oct 11:10 a-third
-rw-r--r--  1 jstocker  jstocker  0  5 Oct 11:08 b-first
-rw-r--r--  1 jstocker  jstocker  0  5 Oct 11:09 c-second


looks very alphabetic

Jan



On Sat, 2003-10-04 at 11:21, Shane Kinney wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I could be wrong, but mine seems to work fine with:
> 
> FreeBSD kappa.freebsdhackers.net 5.1-CURRENT FreeBSD 5.1-CURRENT #19: Wed Oct  1 
> 15:08:00 CDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KAPPA  i386
> 
> Try re-building world.  Hope that helps.
> 
> ~Shane
> 
> IRC: irc.freebsdhackers.net #freebsd
> PGP: http://www.freebsdhackers.net/pgp
> 
> On Sat, 4 Oct 2003, Jan Stocker wrote:
> 
> > On my -current "ls -c" and "ls -u" produce only alphanumeric output, no
> > sort by date my 4.7 box works fine...
> >
> >
> > FreeBSD Twoflower 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Sun Sep 14 14:17:26 CEST 
> > 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/Twoflower50  i386
> >
> >
> >
> > ___
> > [EMAIL PROTECTED] mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.0.6 (FreeBSD)
> Comment: For info see http://www.gnupg.org
> 
> iD8DBQE/fpE0gsso3QO013ERAokYAKCHerMsaQiSkALws1SGcIHEZYkNeQCgugrD
> DMmPKrreXL1/1Uup7rfGOOk=
> =GA6F
> -END PGP SIGNATURE-
-- 
Jan Stocker <[EMAIL PROTECTED]>

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

Re: CDROM / UDMA problem on -current (2 hours old)

[Soren Schmidt]

It seems Jan Stocker wrote:
> I've updates my -current system from Sep, 14th to todays -current (2
> hours old). Now i cant boot further than detecting cdrom drives. After
> testing my second cdrom (cdrw) for its UDMA capabilities the kernel
> hangs in an endless loop. The output is a repeat from two lines which
> are printed so fast i cant really read  but it must be something
> like that:
> 
> acd1: WARNING - REQUEST_UDMA  (error request)
> acd1: WARNING - INQUIRE_SENSE  (retrying request)
> 
> The drive is an 2x2x24x CD/RW from Traxdata which is detected previously
> as:
> 
> acd1: CDRW  at ata1-slave WDMA2

Try a kernel without atapicam ?

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

Re: SMBus / I2C h/w sensors and FreeBSD 5.1

[Dan Naumov]

On Sun, 2003-10-05 at 02:53, Bernd Walter wrote:
> With a driver for the hardware it's possible of course.
> You have a VT82C686A/B chip for which you want viapm driver.
> intpm is for Intel PIIX4 (82371AB, 82443MX) which you don't have.

I've replaced intpm with viapm in my kernel config and this is what I am
seeing in my dmesg now:

viapropm0: SMBus I/O base at 0x5000
viapropm0:  port 0x5000-0x500f at
device 7.4 on pci0
viapropm0: failed to enable port mapping!
viapropm0: could not allocate bus space
device_probe_and_attach: viapropm0 attach returned 6

Obviously, /dev/smb is still nowhere to be seen :(

Sincerely,
Dan Naumov

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