ACPI problems with Dell laptops? (was: Jerky keyboard and mouse)

2005-11-20 Thread Greg 'groggy' Lehey
On Saturday, 19 November 2005 at 21:37:03 -0600, Stephen Montgomery-Smith wrote:
 I recently upgraded from stable-6 of Nov 4 to stable-6 of today on
 my Dell Latitude D800 Laptop, and suddenly the response of the
 touchpad mouse and keyboard was bery bad.

Heh.  I saw the subject line and thought I wonder if this is a Dell
laptop.

 In particular, when I type about 1 in 10 key presses simply do not
 register.

This, however, is a order of magnitude worse than what I have
experienced with my Inspiron 6100.

 I ended up going back to the Nov 4 stable-6, which fixed the
 problem.

Well, it worked around it.

 Any ideas?  I am happy to provide any details you may need.

I'd guess that this is another ACPI issue like the one I reported a
couple of weeks back.  In my case, it was slow, but I didn't lose any
keystrokes.

What happens when you ping another system?  I found that the ping time
was normal (in the order of 1 µs), but it repeated only every 3
seconds.  When I unloaded ACPI, things worked normally.

I'm following this up to the ACPI list with a reminder that my message
has been there for 2 weeks.  How do I localize the problem?

Greg
--
See complete headers for address and phone numbers
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Centralized building

2005-11-20 Thread Eirik Øverby


On Nov 19, 2005, at 19:43 , Joseph Koshy wrote:


AFAICT cross-compiling amd64 on a i386 machine isn't supported
yet. I ran into a similar problem when I upgraded an i386
machine to amd64. I thought I could just set CPUTYPE=athlon-64
and buildworld would do the right thing. Apparently not.


Bootstrapping a single machine is supported:

# make buildworld TARGET_ARCH=new-arch

plus a few other steps.  (See build(7)).

There have been a couple of postings on the mailing lists
on this topic in the recent past.  I've taken a stab at
describing how to cross-bootstrap too:

http://edoofus.blogspot.com/2005/10/cross-building-freebsd.html

The OP wanted to do a 'buildworld TARGET_ARCH=foo' on one
machine and then an 'installworld' on a different set of
machines.


Yes, and he still wonders if this is supposed to be doable or not.
I think the culprit is (partly) the fact that every architecture is  
built into its own subdirectory in /usr/obj, EXCEPT the architecture  
the build is running on. The same goes for the install part, and if  
the build and install architectures differ, it cannot ever work.  
Setting MAKEOBJDIRPREFIX on the target host makes the install start,  
but it fails after a couple of minutes with the dd: not found error.
(I do notice that there is a /usr/obj/usr directory created also when  
cross-building; I'm assuming this contains the build bootstrap tools).






--
FreeBSD Volunteer, http://people.freebsd.org/~jkoshy




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


Re: Centralized building

2005-11-20 Thread Eirik Øverby


On Nov 20, 2005, at 09:50 , Eirik Øverby wrote:



On Nov 19, 2005, at 19:43 , Joseph Koshy wrote:


AFAICT cross-compiling amd64 on a i386 machine isn't supported
yet. I ran into a similar problem when I upgraded an i386
machine to amd64. I thought I could just set CPUTYPE=athlon-64
and buildworld would do the right thing. Apparently not.


Bootstrapping a single machine is supported:

# make buildworld TARGET_ARCH=new-arch

plus a few other steps.  (See build(7)).

There have been a couple of postings on the mailing lists
on this topic in the recent past.  I've taken a stab at
describing how to cross-bootstrap too:

http://edoofus.blogspot.com/2005/10/cross-building-freebsd.html

The OP wanted to do a 'buildworld TARGET_ARCH=foo' on one
machine and then an 'installworld' on a different set of
machines.


Yes, and he still wonders if this is supposed to be doable or not.
I think the culprit is (partly) the fact that every architecture is  
built into its own subdirectory in /usr/obj, EXCEPT the  
architecture the build is running on. The same goes for the install  
part, and if the build and install architectures differ, it cannot  
ever work. Setting MAKEOBJDIRPREFIX on the target host makes the  
install start, but it fails after a couple of minutes with the dd:  
not found error.
(I do notice that there is a /usr/obj/usr directory created also  
when cross-building; I'm assuming this contains the build bootstrap  
tools).


Follow-up. If I enter src/sys and do a make install, the dd step  
works perfectly - however it stops later when trying to install  
cdboot. I am assuming this is due to missing options or wrong target  
for make, but - from all I can tell - shows a weakness in the build/ 
install system. Or maybe not...


Anyone??

/Eirik







--
FreeBSD Volunteer, http://people.freebsd.org/~jkoshy




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





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


Mount related panic with FreeBSD 6?

2005-11-20 Thread Václav Haisman
Hi,
I got this panic on freshly installed FreeBSD 6. I did this df -h and
noticed that /mnt/oldroot/home is somewhat mangled. The /mnt/oldroot is
root of FreeBSD 4.11 system. I successfully copied some settings and all
user accounts from that /mnt/oldroot/home earlier today. This is what I
did before the panic:

logout::wilx:~ df -h
FilesystemSize  Used Avail Use% Mounted on
/dev/ad0s1a   496M   57M  399M  13% /
devfs 1.0k  1.0k 0 100% /dev
/dev/ad0s1e   989M   12k  910M   1% /tmp
/dev/ad0s1f   163G   29G  120G  20% /usr
/dev/ad0s1d   4.8G  2.0G  2.4G  45% /var
/dev/ad2s1a   492M  317M  136M  70% /mnt/oldroot
df: `/mnt/oldroot/hom': No such file or directory
/dev/ad2s1f   6.7G  5.3G 1013M  85% /mnt/oldroot/usr
/dev/ad2s1e   2.9G  2.2G  476M  83% /mnt/oldroot/var

logout::root:~ mount /mnt/oldroot/home

Notice that /mnt/oldroot/home is mounted twice here:

logout::root:~ mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, local, soft-updates)
/dev/ad0s1d on /var (ufs, local, soft-updates)
/dev/ad2s1a on /mnt/oldroot (ufs, local, read-only)
/dev/ad2s1g on /mnt/oldroot/home (ufs, local, read-only)
/dev/ad2s1f on /mnt/oldroot/usr (ufs, local, read-only)
/dev/ad2s1e on /mnt/oldroot/var (ufs, local, read-only)
/dev/ad2s1g on /mnt/oldroot/home (ufs, local, read-only)

logout::root:~ umount /mnt/oldroot/home

logout::root:~ mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, local, soft-updates)
/dev/ad0s1d on /var (ufs, local, soft-updates)
/dev/ad2s1a on /mnt/oldroot (ufs, local, read-only)
/dev/ad2s1g on /mnt/oldroot/home (ufs, local, read-only)
/dev/ad2s1f on /mnt/oldroot/usr (ufs, local, read-only)
/dev/ad2s1e on /mnt/oldroot/var (ufs, local, read-only)

logout::root:~ cd /mnt/oldroot/home

logout::root:/mnt/oldroot/home ls

After the ls it panicked. The only thing I see in logs is this:

Nov 20 12:42:02 logout savecore: reboot after panic: page fault
Nov 20 12:42:02 logout savecore: writing core to vmcore.0

Unfortunatelly trying gdb on the core didn't help.  The kernel is still
the generic one from the release CD:

warning: /var/crash/vmcore.0: no core file handler recognizes format,
using default
Can't fetch registers from this type of core file
Can't fetch registers from this type of core file
#0  0x in ?? ()

I realise that this might have been already fixed after the release. I
will try to cvsup the sources and build a new kernel.

Vaclav Haisman


signature.asc
Description: OpenPGP digital signature


FBSD 6-STABLE usb problem: umass0: BBB reset failed, IOERROR

2005-11-20 Thread Holger Kipp
Hello,

whilst copying files from SD-Card via usb card reader
with mcopy, I encountered the following error with
FreeBSD 6.0-STABLE from 15.11.2005. Even though the
device was reattached automatically (nice improvement, btw!), 
this error is very annoying. 
  Is this behaviour already known, or should I file a pr?
Apart from the reattachement, I had a similar behaviour under
5.4-STABLE.

Regards,
Holger Kipp


%mcopy -mpv h:photos/51\* ./
Copying H:/photos/51011001.jpg
Copying H:/photos/51011002.jpg
..
Copying H:/photos/51109003.jpg
Copying H:/photos/51109005.jpg
Copying H:/photos/51109007.jpg
plain_io: Input/output error
file read: Input/output error
Copying H:/photos/5008.jpg
plain_io: Device not configured
file read: Device not configured
Copying H:/photos/51112001.jpg
plain_io: Device not configured
file read: Device not configured


with /var/log/messages saying:

Nov 20 13:14:54 katrin kernel: umass0: BBB reset failed, IOERROR
Nov 20 13:14:54 katrin kernel: umass0: BBB bulk-in clear stall failed, IOERROR
Nov 20 13:14:54 katrin kernel: umass0: at uhub4 port 8 (addr 3) disconnected
Nov 20 13:14:54 katrin kernel: (da0:umass-sim0:0:0:0): lost device
Nov 20 13:14:54 katrin kernel: (da0:umass-sim0:0:0:0): removing device entry
Nov 20 13:14:54 katrin kernel: (da1:umass-sim0:0:0:1): lost device
Nov 20 13:14:54 katrin kernel: (da1:umass-sim0:0:0:1): removing device entry
Nov 20 13:14:54 katrin kernel: (da2:umass-sim0:0:0:2): lost device
Nov 20 13:14:54 katrin kernel: (da2:umass-sim0:0:0:2): removing device entry
Nov 20 13:14:54 katrin kernel: (da3:umass-sim0:0:0:3): lost device
Nov 20 13:14:54 katrin kernel: umass0: detached
Nov 20 13:14:54 katrin kernel: (da3:umass-sim0:0:0:3): Synchronize cache 
failed, status == 0x39, scsi status == 0x0
Nov 20 13:14:54 katrin kernel: (da3:umass-sim0:0:0:3): removing device entry
Nov 20 13:14:56 katrin kernel: umass0: SMSC 223 USB97C223, rev 2.00/1.95, addr 3
...(omitted parts for 0:0:0-0:0:2)
Nov 20 13:14:56 katrin kernel: da3 at umass-sim0 bus 0 target 0 lun 3
Nov 20 13:14:56 katrin kernel: da3: SMSC 223 U HS-SD/MMC 1.95 Removable 
Direct Access SCSI-0 device 
Nov 20 13:14:56 katrin kernel: da3: 40.000MB/s transfers
Nov 20 13:14:56 katrin kernel: da3: 483MB (990976 512 byte sectors: 64H 32S/T 
483C)

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


Re: message too long when sending broadcasts

2005-11-20 Thread Robert Watson


On Sun, 20 Nov 2005, Michael Voucko wrote:



Berkeley-derived kernels do not allow a broadcast datagram to be 
fragmented. If the size of an IP datagram that is being sent to a 
broadcast address exceeds the outgoing interface MTU, EMSGSIZE is 
returned (pp. 233?234 of TCPv2). This is a policy decision that has 
existed since 4.2BSD. There is nothing that prevents a kernel from 
fragmenting a broadcast datagram, but the feeling is that broadcasting 
puts enough load on the network as it is, so there is no need to 
multiply this load by the number of fragments.  AIX, FreeBSD, and 
MacOS implement this limitation. Linux, Solaris, and HP-UX fragment 
datagrams sent to a broadcast address.


Maybe it's worth adding this information somewhere to make it easier to 
find?


It would also be quite easy to make this configurable -- the code in 
ip_output is fairly straight forward:


/*
 * Look for broadcast address and
 * verify user is allowed to send
 * such a packet.
 */
if (isbroadcast) {
if ((ifp-if_flags  IFF_BROADCAST) == 0) {
error = EADDRNOTAVAIL;
goto bad;
}
if ((flags  IP_ALLOWBROADCAST) == 0) {
error = EACCES;
goto bad;
}
/* don't allow broadcast messages to be fragmented */
if (ip-ip_len  ifp-if_mtu) {
error = EMSGSIZE;
goto bad;
}
if (flags  IP_SENDONES)
ip-ip_dst.s_addr = INADDR_BROADCAST;
m-m_flags |= M_BCAST;
} else {
m-m_flags = ~M_BCAST;
}

We could add a global option, or maybe just an IP socket option.

Robert N M Watson
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


FBSD-6 usb/scanner-access-rights

2005-11-20 Thread Holger Kipp
Hello,

I am slightly unsatisfied with user rights management,
especially with usb-devices, but also with access to
cd/dvd-burners for the following reason:

I'd like to be able to allow access to burners that
are accessed as scsi-devices (via atapicam) for some
users, but for that to work it is not sufficient to
allow access via cd0/cd1, but I also have to allow
the corresponding passx-devices. For usb-scanner 
it is even worse. If I allow access to uscanner0,
this does not work unless I also allow the corresponding
/dev/usbx-device.
umassx is also accessed as dax-device and also 
therefore needs some da-devices to be allowed rw-access
for 'ordinary' users. I don't relly like to allow direct
access to the related devices (dax, passy  - especially 
if the system is using scsi-disks).

Is there an easy way to name the devices a user might
be allowed to access rw, without compromising the system?
I don't want to give operator group to these users,
and I don't want to blindly allow access to some 
da- or pass-devices where I cannot determine the order
of numbering easily.

I hope this does not sound ignorant. Pointers to helpful
information are also welcome :-)


Regards,
Holger Kipp
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re : Re: building gnome2 on freebsd6-stable

2005-11-20 Thread Didier Wiroth
thanks for replying.

No, I actually did not have gnome installed, as I'm running fluxbox but may be 
I had some sub-gnome ports installed that I didn't notice and that are 
responsible for the build failure. 

May be I should uninstall all *gnome* ports and restart.

Best regards,
Didier

- Message d'origine -
De: Paul Root [EMAIL PROTECTED]
Date: Samedi, Novembre 19, 2005 11:26 pm
Objet: Re: building gnome2 on freebsd6-stable

 Did you have gnome in before and you started to
 try to build it?
 
 Go to http://www.freebsd.org/gnome. There is an
 upgrade script there. I used it partially, it got
 me about half way. Turned out that I had an ethernet
 speed/duplex issue much of the time, and was having
 trouble downloading.
 
 After a day of manually downloading (ftp worked, fetch,
 which is used by the script had trouble) and restarting the
 script, I gave up on it and used portmanager. That worked
 better, but still had a couple of issues.
 
 About this time, I got the duplex issue fixed on the switch,
 and then went back to /usr/ports/x11/gnome2 and from there
 everything worked.
 
 The problem is that you'll get out of order with dependancies
 if you just start in /usr/ports/x11/gnome2.
 
 
 I'm having one problem with gnome 2.12. The screensaver won't
 start up. It complains about  not being able to contact the
 messagebus. Any help here?
 
 
 
 Didier Wiroth wrote:
  ***
  This message has been scanned by the InterScan for CSC-SSM and 
 found to be free of known security risks.
  ***
  
  
  hi,
  
  I tried to build gnome2 on freebsd6 stable.
  
  It fails when it tries to compile gnomeapllets2, here is the output:
  --START SNIP-
  12.1/drivemount/help'
  if ! test -d es/; then mkdir es/; fi
  if test -f C/drivemount.xml; then d=../; else d=.././; fi; \
  (cd es/  \
`which xml2po` -e -p \
  ${d}es/es.po \
  ${d}C/drivemount.xml  drivemount.xml.tmp  \
  cp drivemount.xml.tmp drivemount.xml  rm -f 
 drivemount.xml.tmp) Traceback (most recent call last):
File /usr/X11R6/bin/xml2po, line 34, in ?
  import libxml2
File /usr/local/lib/python2.4/site-packages/libxml2.py, line 
 1, in ?
  import libxml2mod
  ImportError: /usr/local/lib/python2.4/site-
 packages/libxml2mod.so: Undefined symbol xmlParseURIRaw
  gmake[3]: *** [es/drivemount.xml] Error 1
  gmake[3]: Leaving directory 
 `/usr/ports/x11/gnomeapplets2/work/gnome-applets-
 2.12.1/drivemount/help' gmake[2]: *** [all-recursive] Error 1
  gmake[2]: Leaving directory 
 `/usr/ports/x11/gnomeapplets2/work/gnome-applets-2.12.1/drivemount'
  gmake[1]: *** [all-recursive] Error 1
  gmake[1]: Leaving directory 
 `/usr/ports/x11/gnomeapplets2/work/gnome-applets-2.12.1'
  gmake: *** [all] Error 2
  *** Error code 2
  
  Stop in /usr/ports/x11/gnomeapplets2.
  *** Error code 1
  
  Stop in /usr/ports/x11/gnome2.
  -STOP SNIP--
  
  What can I do to solve the problem?
  
  thanks a lot
  didier
  
  ___
  freebsd-stable@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-stable
  To unsubscribe, send any mail to freebsd-stable-
 [EMAIL PROTECTED]
 

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


Re: FBSD-6 usb/scanner-access-rights

2005-11-20 Thread Roland Smith
On Sun, Nov 20, 2005 at 02:16:24PM +0100, Holger Kipp wrote:
 
 Is there an easy way to name the devices a user might
 be allowed to access rw, without compromising the system?
 I don't want to give operator group to these users,
 and I don't want to blindly allow access to some 
 da- or pass-devices where I cannot determine the order
 of numbering easily.

One thing you could do is make the groups usb and cdrom and make them
the groups owning the relevant devices, e.g. by putting the following in
/etc/devfs.rules:

add path 'da*s*' mode 0660 group usb
add path 'uscanner*' mode 0660 group usb

The ownership for the CD-ROM devices should be set in /etc/devfs.conf:

# Give members of group cdrom access to the CD/DVD-ROM and DVD+RW via the
# SCSI interface
own xpt0root:cdrom
permxpt00660

own cd0 root:cdrom
permcd0 0660
linkcd0 cdrom
linkcd0 dvd

own pass0   root:cdrom
permpass0   0660

own cd1 root:cdrom
permcd1 0660

own pass1   root:cdrom
permpass1   0660

The user that must be able to use the CD-ROMs and scanner must be a
member of the appropriate group.

If that is not fine-grained enough, maybe ACLs might help. See setfacl(1).

Roland
-- 
R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text.
public key: http://www.xs4all.nl/~rsmith/pubkey.txt


pgpx5NlZ2BPe3.pgp
Description: PGP signature


Re: FBSD-6 usb/scanner-access-rights

2005-11-20 Thread Holger Kipp
Dear Roland,

thank you very much for your answer.

On Sun, Nov 20, 2005 at 03:04:22PM +0100, Roland Smith wrote:
 On Sun, Nov 20, 2005 at 02:16:24PM +0100, Holger Kipp wrote:
  
  Is there an easy way to name the devices a user might
  be allowed to access rw, without compromising the system?
  I don't want to give operator group to these users,
  and I don't want to blindly allow access to some 
  da- or pass-devices where I cannot determine the order
  of numbering easily.
 
 One thing you could do is make the groups usb and cdrom and make them
 the groups owning the relevant devices, e.g. by putting the following in
 /etc/devfs.rules:
 
 add path 'da*s*' mode 0660 group usb
 add path 'uscanner*' mode 0660 group usb

ah, I had the entry 
add path 'uscanner*' mode 0660 group usb 
missing in the devfs.rules-file
but this still does not help...

uscanner0 is here:

uscanner0: EPSON EPSON Scanner, rev 1.10/1.00, addr 2


sane-find-scanner has the following to say:
found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0

only if I also issue
# chown root:usb /dev/usb0
# chown root:usb /dev/usb1
# chown root:usb /dev/usb2

it will return
found USB scanner (vendor=0x04b8, product=0x011d) at /dev/uscanner0

this is not good either, because attaching the scanner to a different
device means I have to change this for all /dev/usb*, effectively
allowing read/write to all usb devices.

I wonder why I have to allow access to all devices from 0 to 2.

Attaching to a different hub(*):
uscanner0: at uhub2 port 2 (addr 2) disconnected
uscanner0: detached
uscanner0: EPSON EPSON Scanner, rev 1.10/1.00, addr 2

- I also have to chgrp usb /dev/usb3

so all /dev/usbx up to the corresponding /dev/usby where the
scanner is attached are needed. Strange!

(*) detaching gives:
uscanner0: at uhub3 port 1 (addr 2) disconnected
uscanner0: detached

 The ownership for the CD-ROM devices should be set in /etc/devfs.conf:
 
 # Give members of group cdrom access to the CD/DVD-ROM and DVD+RW via the
 # SCSI interface
 own xpt0root:cdrom
 permxpt00660
 
 own cd0 root:cdrom
 permcd0 0660
 linkcd0 cdrom
 linkcd0 dvd
 
 own pass0   root:cdrom
 permpass0   0660
 
 own cd1 root:cdrom
 permcd1 0660
 
 own pass1   root:cdrom
 permpass1   0660
 
 The user that must be able to use the CD-ROMs and scanner must be a
 member of the appropriate group.
 

Yes, but there is a problem with numbering of pass-devices:

with card-reader attached during boot, I have:
SMSC 223 U HS-CF 1.95at scbus0 target 0 lun 0 (da0,pass0)
SMSC 223 U HS-MS 1.95at scbus0 target 0 lun 1 (da1,pass1)
SMSC 223 U HS-SM 1.95at scbus0 target 0 lun 2 (da2,pass2)
SMSC 223 U HS-SD/MMC 1.95at scbus0 target 0 lun 3 (da3,pass3)
HL-DT-ST DVDRAM GSA-4163B A102   at scbus2 target 0 lun 0 (pass4,cd0)
HL-DT-ST RW/DVD GCC-4120B 2.01   at scbus2 target 1 lun 0 (pass5,cd1)

attaching card-reader afterwards gives different numbering:
after boot:
katrin# camcontrol devlist
HL-DT-ST DVDRAM GSA-4163B A102   at scbus1 target 0 lun 0 (cd1,pass1)
HL-DT-ST RW/DVD GCC-4120B 2.01   at scbus1 target 1 lun 0 (cd0,pass0)
after attaching cardreader:
katrin# camcontrol devlist
HL-DT-ST DVDRAM GSA-4163B A102   at scbus1 target 0 lun 0 (cd1,pass1)
HL-DT-ST RW/DVD GCC-4120B 2.01   at scbus1 target 1 lun 0 (cd0,pass0)
SMSC 223 U HS-CF 1.95at scbus4 target 0 lun 0 (da0,pass2)
SMSC 223 U HS-MS 1.95at scbus4 target 0 lun 1 (da1,pass3)
SMSC 223 U HS-SM 1.95at scbus4 target 0 lun 2 (da2,pass4)
SMSC 223 U HS-SD/MMC 1.95at scbus4 target 0 lun 3 (da3,pass5)

so allowing access to cd0/cd1 and corresponding pass0 and pass1 will
break if computer is booted with usb-cardreader attached. not good.

And: allowing specific users access to xpt might also not be a very
good idea according to the man-page:
 Since the xpt driver allows direct access to the CAM subsystem, system
 administrators should exercise caution when granting access to this
 driver.  If used improperly, this driver can allow userland applications
 to crash a machine or cause data loss.

 If that is not fine-grained enough, maybe ACLs might help. See setfacl(1).

so we currently have:

- rights needed not only for the device itself, but also for the bus
  and or control devices (passx, usbx, xpt0)
- dynamic numbering (passx).

I agree that usb is a nightmare and should never have happened.

Regards,
Holger Kipp

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


Re: FBSD-6 usb/scanner-access-rights

2005-11-20 Thread Roland Smith
On Sun, Nov 20, 2005 at 05:37:36PM +0100, Holger Kipp wrote:
 Dear Roland,
 
 thank you very much for your answer.
 
 On Sun, Nov 20, 2005 at 03:04:22PM +0100, Roland Smith wrote:
  On Sun, Nov 20, 2005 at 02:16:24PM +0100, Holger Kipp wrote:
   
   Is there an easy way to name the devices a user might
   be allowed to access rw, without compromising the system?
   I don't want to give operator group to these users,
   and I don't want to blindly allow access to some 
   da- or pass-devices where I cannot determine the order
   of numbering easily.
  
  One thing you could do is make the groups usb and cdrom and make them
  the groups owning the relevant devices, e.g. by putting the following in
  /etc/devfs.rules:
  
  add path 'da*s*' mode 0660 group usb
  add path 'uscanner*' mode 0660 group usb
 
 ah, I had the entry 
 add path 'uscanner*' mode 0660 group usb 
 missing in the devfs.rules-file
 but this still does not help...
 
 uscanner0 is here:
 
 uscanner0: EPSON EPSON Scanner, rev 1.10/1.00, addr 2
 
 
 sane-find-scanner has the following to say:
 found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0

Doesn't matter that you get UNKNOWN. It _will_ work with sane without
access to /dev/usb*. It does here.

snip
 Yes, but there is a problem with numbering of pass-devices:
 
 with card-reader attached during boot, I have:
 SMSC 223 U HS-CF 1.95at scbus0 target 0 lun 0 (da0,pass0)
 SMSC 223 U HS-MS 1.95at scbus0 target 0 lun 1 (da1,pass1)
 SMSC 223 U HS-SM 1.95at scbus0 target 0 lun 2 (da2,pass2)
 SMSC 223 U HS-SD/MMC 1.95at scbus0 target 0 lun 3 (da3,pass3)
 HL-DT-ST DVDRAM GSA-4163B A102   at scbus2 target 0 lun 0 (pass4,cd0)
 HL-DT-ST RW/DVD GCC-4120B 2.01   at scbus2 target 1 lun 0 (pass5,cd1)
 
 attaching card-reader afterwards gives different numbering:
 after boot:
 katrin# camcontrol devlist
 HL-DT-ST DVDRAM GSA-4163B A102   at scbus1 target 0 lun 0 (cd1,pass1)
 HL-DT-ST RW/DVD GCC-4120B 2.01   at scbus1 target 1 lun 0 (cd0,pass0)
 after attaching cardreader:
 katrin# camcontrol devlist
 HL-DT-ST DVDRAM GSA-4163B A102   at scbus1 target 0 lun 0 (cd1,pass1)
 HL-DT-ST RW/DVD GCC-4120B 2.01   at scbus1 target 1 lun 0 (cd0,pass0)
 SMSC 223 U HS-CF 1.95at scbus4 target 0 lun 0 (da0,pass2)
 SMSC 223 U HS-MS 1.95at scbus4 target 0 lun 1 (da1,pass3)
 SMSC 223 U HS-SM 1.95at scbus4 target 0 lun 2 (da2,pass4)
 SMSC 223 U HS-SD/MMC 1.95at scbus4 target 0 lun 3 (da3,pass5)
 
 so allowing access to cd0/cd1 and corresponding pass0 and pass1 will
 break if computer is booted with usb-cardreader attached. not good.

It was an example. I don't have many usb devices, so it works for me. :-)

  If that is not fine-grained enough, maybe ACLs might help. See setfacl(1).
 
 so we currently have:
 
 - rights needed not only for the device itself, but also for the bus
   and or control devices (passx, usbx, xpt0)

Yes, but ACL give fine-grained access control. And no matter how you
look at it, you _have_ to trust the person whom you give access to the
pass devices. It's in the FreeBSD architecture.

 - dynamic numbering (passx).
 
 I agree that usb is a nightmare and should never have happened.

:-)

For disc devices, you could use GEOM_LABEL. That'll give you consistent
/dev/label/ names.

Roland
-- 
R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text.
public key: http://www.xs4all.nl/~rsmith/pubkey.txt


pgpr0N6RwiSpt.pgp
Description: PGP signature


inconsistent arp(8) mac address output using if_bridge

2005-11-20 Thread Niki Denev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I have a small machine setup to act as simple network gateway.
I have one wireless and one wired interfaces without IP configuration
on them, and they are added as if_bridge(4) members.
When i issue arp -na command on the machine i get this:

? (10.10.10.240) at 0.14.a5.1a.dc.73 on bridge0
? (10.10.10.241) at 4.4b.80.80.80.3 on bridge0
? (10.10.10.246) at 0.a0.cc.62.99.c3 on bridge0
? (10.10.10.253) at 0.5.4e.4f.7b.eb on bridge0
? (172.16.1.1) at 00:30:48:83:93:e9 on ep0 [ethernet]
? (172.16.37.9) at 00:0f:b0:01:30:c0 on ep0 [ethernet]

While the mac addresses appear to be correct, maybe
this should be fixed to be consistent with the default
mac address output?

- --niki
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDgLd0HNAJ/fLbfrkRAt37AKDJ5P9PC1tf6VCyBDv83KwjNTqirwCgvhoW
noztCOr2cpcaEqEjiBLAclc=
=7DFZ
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: inconsistent arp(8) mac address output using if_bridge

2005-11-20 Thread Niki Denev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Niki Denev wrote:
 Hello,
 
 I have a small machine setup to act as simple network gateway.
 I have one wireless and one wired interfaces without IP configuration
 on them, and they are added as if_bridge(4) members.
 When i issue arp -na command on the machine i get this:
 
 ? (10.10.10.240) at 0.14.a5.1a.dc.73 on bridge0
 ? (10.10.10.241) at 4.4b.80.80.80.3 on bridge0
 ? (10.10.10.246) at 0.a0.cc.62.99.c3 on bridge0
 ? (10.10.10.253) at 0.5.4e.4f.7b.eb on bridge0
 ? (172.16.1.1) at 00:30:48:83:93:e9 on ep0 [ethernet]
 ? (172.16.37.9) at 00:0f:b0:01:30:c0 on ep0 [ethernet]
 
 While the mac addresses appear to be correct, maybe
 this should be fixed to be consistent with the default
 mac address output?
 
 --niki

Sorry, forgot the mention the os version :

FreeBSD gimli 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov  3 09:36:13
UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386

- --niki
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFDgLlYHNAJ/fLbfrkRAnM8AJ0WbFS29X9F3FTah1S3Rnb/P7BZOgCeNeTr
at9AxPhl6kvnVV7XBFY3lns=
=Tgdb
-END PGP SIGNATURE-
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FBSD-6 usb/scanner-access-rights

2005-11-20 Thread Holger Kipp
On Sun, Nov 20, 2005 at 06:47:54PM +0100, Roland Smith wrote:
 On Sun, Nov 20, 2005 at 05:37:36PM +0100, Holger Kipp wrote:
  Dear Roland,
Is there an easy way to name the devices a user might
be allowed to access rw, without compromising the system?
I don't want to give operator group to these users,
and I don't want to blindly allow access to some 
da- or pass-devices where I cannot determine the order
of numbering easily.

  ah, I had the entry 
  add path 'uscanner*' mode 0660 group usb 
  missing in the devfs.rules-file
  but this still does not help...
  
  uscanner0 is here:
  uscanner0: EPSON EPSON Scanner, rev 1.10/1.00, addr 2
  
  sane-find-scanner has the following to say:
  found USB scanner (UNKNOWN vendor and product) at device /dev/uscanner0
 
 Doesn't matter that you get UNKNOWN. It _will_ work with sane without
 access to /dev/usb*. It does here.

This is an Epson Perfection 1260. Don't ask what the 'Perfection' stands
for. Anyway, this is in fact a Plustek, so I have to add the following
to /usr/local/etc/sane.d/plustek.conf:
-[usb]
+[usb] 0x04B8 0x011D
+device /dev/uscanner0

I need vendor and product id to get this working. Without getting
this info, eg scanimage -L will complain that it couldn't find a scanner, etc.

only with /dev/usb* set to root:usb, I will get

%scanimage -L
device `plustek:/dev/uscanner0' is a Epson Perfection 1260/Photo USB flatbed 
scanner

Regards,
Holger Kipp
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: FreeBSD unstable on Dell 1750 using SMP?

2005-11-20 Thread Rutger Bevaart

Strange indeed.

On a 1750 with bge's:
475 mbufs in use
501/25600 mbuf clusters in use (current/max)
0/3/6656 sfbufs in use (current/peak/max)
1120 KBytes allocated to network
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
100 calls to protocol drain routines

On a 2850 (hardware identical to an 1850):
$ netstat -m
4294966848 mbufs in use
565/25600 mbuf clusters in use (current/max)
0/67/6656 sfbufs in use (current/peak/max)
1018 KBytes allocated to network
0 requests for sfbufs denied
0 requests for sfbufs delayed
16449 requests for I/O initiated by sendfile
589 calls to protocol drain routines

Both experience the auto reboot feature. The mbufs on the 2850 look  
like a counter (signed/unsigned) bug, maybe even just in the  
printing. Other than that I'm having a hard time interpreting these  
results.


Regards
Rutger Bevaart

On Nov 20, 2005, at 5:07 PM, Gino Ruopolo wrote:



Hello Rutger,

I red your post but I'm unable to reply on the list 'cause of some  
firewall settings.


I'm having the same problems  with various Dell1850 and Fbsd 5.4

Last week I noticed the following:

#netstat -m
4294899289 mbufs in use!?!?!??!!?
4294940375/25600 mbuf clusters in use (current/max) !?!?!?!??!
0/9/6656 sfbufs in use (current/peak/max)
4123460 KBytes allocated to network
0 requests for sfbufs denied
0 requests for sfbufs delayed
34 requests for I/O initiated by sendfile
2533 calls to protocol drain routines

Here is the output of the same command on a different server with  
fxp0 ethernet driver, also FBSD 5.4 and doing the same work:


#netstat -m
194 mbufs in use
171/25600 mbuf clusters in use (current/max)
0/4/6656 sfbufs in use (current/peak/max)
390 KBytes allocated to network
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

So I've tried putting an old pci ethernet 10/100 using fxp driver  
on a Dell1850 suffering the self-reboot problem.  I'm getting 5  
days of uptime without a single reboot ...


What about a problem with the em driver?

Regards,
gino

_
Parla con i tuoi amici che hanno MSN Hotmail in tempo reale! E'  
gratis. http://www.imagine-msn.com/messenger/default.aspx?locale=it-IT




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


Re: inconsistent arp(8) mac address output using if_bridge

2005-11-20 Thread Andrew Thompson
On Sun, Nov 20, 2005 at 07:50:44PM +0200, Niki Denev wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hello,
 
 I have a small machine setup to act as simple network gateway.
 I have one wireless and one wired interfaces without IP configuration
 on them, and they are added as if_bridge(4) members.
 When i issue arp -na command on the machine i get this:
 
 ? (10.10.10.240) at 0.14.a5.1a.dc.73 on bridge0
 ? (10.10.10.241) at 4.4b.80.80.80.3 on bridge0
 ? (10.10.10.246) at 0.a0.cc.62.99.c3 on bridge0

This has been fixed up already, you can update your source and recompile
usr.sbin/arp

HEAD: r1.59
RELENG_6: r1.58.2.1


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


Re: FBSD-6 usb/scanner-access-rights

2005-11-20 Thread Roland Smith
On Sun, Nov 20, 2005 at 07:26:38PM +0100, Holger Kipp wrote:
  Doesn't matter that you get UNKNOWN. It _will_ work with sane without
  access to /dev/usb*. It does here.
 
 This is an Epson Perfection 1260. Don't ask what the 'Perfection' stands
 for. Anyway, this is in fact a Plustek, so I have to add the following
 to /usr/local/etc/sane.d/plustek.conf:
 -[usb]
 +[usb] 0x04B8 0x011D
 +device /dev/uscanner0

My Epson Perfection 1650 only needs the last line in epson.conf to work
with the xsane gimp plug-in. No vendor or device IDs necessary. I don't
use scanimage. Try copying plustek.conf to epson.conf, and adding
epson to dll.conf.

The permissions on the uscanner device are 660 for root:usb. The
/dev/usb devices are 660 for root:operator. My user-id is not in the
operator group.

Roland
-- 
R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text.
public key: http://www.xs4all.nl/~rsmith/pubkey.txt


pgpv61ZBfa5PW.pgp
Description: PGP signature


is removable_interfaces still used?

2005-11-20 Thread Ronald Klop

Hello,

I'm running 6.0-STABLE and see that the option removable_interfaces is not  
used in any config script.


/etc# grep -r removable_interfaces *
defaults/rc.conf:removable_interfaces=# Removable network  
interfaces for /etc/pccard_ether.


What is is the use of it now?

I can't find any use of pccard_ifconfig also. But there is no reference of  
the removal of these settings in UPDATING.


Where can I find the latest docs for the best way to config a pccard  
network card?


Ronald.

--
 Ronald Klop
 Amsterdam, The Netherlands
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


cmbat related ACPI change between 6.0-release and Nov 10th -stable sources is making Dell laptops to hang

2005-11-20 Thread Pierre-Luc Drouin

Hi,

Since I upgraded from 6.0-release to 6.0-stable on Nov 10th, my laptop 
hangs for about 1-2 seconds everytime a battery monitoring tool asks for 
the cmbat battery status. My laptop is a Dell Precision M70 and shares 
its motherboard with many other Dell laptops. I can reproduce the 
problem by running acpiconf -i loop or sysctl hw.acpi.battery.life. 
The problem did not exist with 6.0-release, so it has been caused by 
some code change between -release and Nov 10th sources. Disabling cmbat 
with debug.acpi.disabled avoids the laptop to hang. Does someone know 
what change to cmbat related stuff could be causing this problem?


Thank you!

Pierre-Luc Drouin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: cmbat related ACPI change between 6.0-release and Nov 10th -stable sources is making Dell laptops to hang

2005-11-20 Thread Vlad GALU
On 11/20/05, Pierre-Luc Drouin [EMAIL PROTECTED] wrote:
 Hi,

 Since I upgraded from 6.0-release to 6.0-stable on Nov 10th, my laptop
 hangs for about 1-2 seconds everytime a battery monitoring tool asks for
 the cmbat battery status. My laptop is a Dell Precision M70 and shares
 its motherboard with many other Dell laptops. I can reproduce the
 problem by running acpiconf -i loop or sysctl hw.acpi.battery.life.
 The problem did not exist with 6.0-release, so it has been caused by
 some code change between -release and Nov 10th sources. Disabling cmbat
 with debug.acpi.disabled avoids the laptop to hang. Does someone know
 what change to cmbat related stuff could be causing this problem?

  I've seen these too, I was running klaptopd.


 Thank you!

 Pierre-Luc Drouin
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to [EMAIL PROTECTED]



--
If it's there, and you can see it, it's real.
If it's not there, and you can see it, it's virtual.
If it's there, and you can't see it, it's transparent.
If it's not there, and you can't see it, you erased it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Centralized building

2005-11-20 Thread Ruslan Ermilov
On Sun, Nov 20, 2005 at 10:14:37AM +0100, Eirik ?verby wrote:
 
 On Nov 20, 2005, at 09:50 , Eirik ?verby wrote:
 
 
 On Nov 19, 2005, at 19:43 , Joseph Koshy wrote:
 
 AFAICT cross-compiling amd64 on a i386 machine isn't supported
 yet. I ran into a similar problem when I upgraded an i386
 machine to amd64. I thought I could just set CPUTYPE=athlon-64
 and buildworld would do the right thing. Apparently not.
 
 Bootstrapping a single machine is supported:
 
 # make buildworld TARGET_ARCH=new-arch
 
 plus a few other steps.  (See build(7)).
 
 There have been a couple of postings on the mailing lists
 on this topic in the recent past.  I've taken a stab at
 describing how to cross-bootstrap too:
 
 http://edoofus.blogspot.com/2005/10/cross-building-freebsd.html
 
 The OP wanted to do a 'buildworld TARGET_ARCH=foo' on one
 machine and then an 'installworld' on a different set of
 machines.
 
 Yes, and he still wonders if this is supposed to be doable or not.
 I think the culprit is (partly) the fact that every architecture is  
 built into its own subdirectory in /usr/obj, EXCEPT the  
 architecture the build is running on. The same goes for the install  
 part, and if the build and install architectures differ, it cannot  
 ever work. Setting MAKEOBJDIRPREFIX on the target host makes the  
 install start, but it fails after a couple of minutes with the dd:  
 not found error.
 (I do notice that there is a /usr/obj/usr directory created also  
 when cross-building; I'm assuming this contains the build bootstrap  
 tools).
 
 Follow-up. If I enter src/sys and do a make install, the dd step  
 works perfectly - however it stops later when trying to install  
 cdboot. I am assuming this is due to missing options or wrong target  
 for make, but - from all I can tell - shows a weakness in the build/ 
 install system. Or maybe not...
 
 Anyone??
 
We don't support build host != install host, in a strict sense.
But as Joseph pointed out, we do support NFS installs to different
architectures.  The build host != install host is supported only
if a number of conditions are met, most noticeable are that they
should be running the same OS version and the same (or compatible)
CPU, and of course the same set of options (/etc/make.conf, etc.)


Cheers,
-- 
Ruslan Ermilov
[EMAIL PROTECTED]
FreeBSD committer


pgp1ZvisVBXjL.pgp
Description: PGP signature


Re: CF card and /dev filesystem entries

2005-11-20 Thread Brian Candler
On Wed, Nov 16, 2005 at 05:57:12PM +0100, Roland Smith wrote:
  However, when I insert a CF card with normal partioning I need /dev/da0s1,
  and this is not present in the /dev filesystem because the partition table
  has not been read.
 snip
  The only way I can see to *force* the superblock to be read is to attempt to
  mount the whole device as if it were unpartitioned. This is sufficient to
  cause the /dev/da0s1 entry to appear in the /dev filesystem.
 snip
  At this point, everything works as expected.
  
  My question is: is there an easier or more direct way to cause the partition
  table of the CF card to be read and the /dev filesystem to update?
 
 Try 'camcontrol rescan all' (as root).

No joy.

[EMAIL PROTECTED] brian# ls /dev/da0*
/dev/da0
[EMAIL PROTECTED] brian# camcontrol rescan all
Re-scan of bus 0 was successful
Re-scan of bus 1 was successful
Re-scan of bus 2 was successful
Re-scan of bus 3 was successful
[EMAIL PROTECTED] brian# ls /dev/da0*
/dev/da0

Another suggestion was:

 I think devfs is updated when a descriptor on the device
 which was opended for writing is closed.  But you don't
 actually have to write anything.  That means, the following
 command should do it:
 
 # dd if=/dev/null of=/dev/da0 count=0

Now, that does the job:

[EMAIL PROTECTED] brian# dd if=/dev/null of=/dev/da0 count=0
0+0 records in
0+0 records out
0 bytes transferred in 0.28 secs (0 bytes/sec)
[EMAIL PROTECTED] brian# ls -l /dev/da0*
crw-r-  1 root  operator0, 107 Nov 20 21:00 /dev/da0
crw-r-  1 root  operator0, 115 Nov 20 21:00 /dev/da0s1
[EMAIL PROTECTED] brian# 

However, I'm not sure I actually *like* opening my CF card in such a way
that I would be likely to overwrite the partition table if I hit a wrong
key...

Regards,

Brian.

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


ad1: req=0xc2998000 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !!

2005-11-20 Thread Nikolay Pavlov

 Hi. I have an error after upgrade to FreeBSD 6.0-RELEASE in time of booting:

 ad1: req=0xc2998000 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER 
Will Robinson !!
 swap_pager: indefinite bufobj: 0 blkno: 3 size: 4096

 then it's just halt.

 But not everytime, sometime it's booting without any problems and i don't know 
why..

 Here is additional information:

 
==
 # uname -a
 FreeBSD spirit 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Fri Nov 11 17:00:05 UTC 
2005 [EMAIL PROTECTED]:/usr/obj/usr/s
 rc/sys/SPIRIT  i386
 

 # atacontrol list
 ATA channel 0:
 Master:  no device present
 Slave:   ad1 Maxtor 6E040L0/NAR61590 ATA/ATAPI revision 7
 ATA channel 1:
 Master:  no device present
 Slave:   no device present
 

 #pciconf -vl

 [EMAIL PROTECTED]:0:0:class=0x06 card=0x25601458 chip=0x25608086 
rev=0x03 hdr=0x00
 vendor   = 'Intel Corporation'
 device   = '82845G/GL/GV/GE/PE DRAM Controller / Host-Hub I/F Bridge'
 class= bridge
 subclass = HOST-PCI
 [EMAIL PROTECTED]:2:0:  class=0x03 card=0x25621458 chip=0x25628086 
rev=0x03 hdr=0x00
 vendor   = 'Intel Corporation'
 device   = '82845G/GL/GV/GE/PE Integrated Graphics Device'
 class= display
 subclass = VGA
 [EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x24c21458 chip=0x24c28086 
rev=0x02 hdr=0x00
 vendor   = 'Intel Corporation'
 device   = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1'
 class= serial bus
 subclass = USB
 [EMAIL PROTECTED]:29:1:class=0x0c0300 card=0x24c21458 chip=0x24c48086 
rev=0x02 hdr=0x00
 vendor   = 'Intel Corporation'
 device   = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2'
 class= serial bus
 subclass = USB
 [EMAIL PROTECTED]:29:2:class=0x0c0300 card=0x24c21458 chip=0x24c78086 
rev=0x02 hdr=0x00
 vendor   = 'Intel Corporation'
 device   = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3'
 class= serial bus
 subclass = USB
 [EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x50061458 chip=0x24cd8086 
rev=0x02 hdr=0x00
 vendor   = 'Intel Corporation'
 device   = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB 2.0 EHCI Controller'
 class= serial bus
 subclass = USB
 [EMAIL PROTECTED]:30:0:class=0x060400 card=0x chip=0x244e8086 
rev=0x82 hdr=0x01
 vendor   = 'Intel Corporation'
 device   = '82801BA/CA/DB/DBL/EB/ER/FB (ICH2/3/4/4/5/5/6), 6300ESB Hub 
Interface to PCI Bridge'
 class= bridge
 subclass = PCI-PCI
 [EMAIL PROTECTED]:31:0:class=0x060100 card=0x chip=0x24c08086 
rev=0x02 hdr=0x00
 vendor   = 'Intel Corporation'
 device   = '82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge'
 class= bridge
 subclass = PCI-ISA
 [EMAIL PROTECTED]:31:1:  class=0x01018a card=0x24c21458 chip=0x24cb8086 
rev=0x02 hdr=0x00
 vendor   = 'Intel Corporation'
 device   = '82801DB/DBL (ICH4/ICH4-L) UltraATA/100 EIDE Controller'
 class= mass storage
 subclass = ATA
 [EMAIL PROTECTED]:31:3:class=0x0c0500 card=0x24c21458 chip=0x24c38086 
rev=0x02 hdr=0x00
 vendor   = 'Intel Corporation'
 device   = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller'
 class= serial bus
 subclass = SMBus
 [EMAIL PROTECTED]:0:0:   class=0x02 card=0x10048086 chip=0x10048086 
rev=0x02 hdr=0x00
 vendor   = 'Intel Corporation'
 device   = '82543GC Gigabit Ethernet Controller (Copper)'
 class= network
 subclass = ethernet
 [EMAIL PROTECTED]:5:0:   class=0x02 card=0xe0001458 chip=0x813910ec 
rev=0x10 hdr=0x00
 vendor   = 'Realtek Semiconductor'
 device   = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter'
 class= network
 subclass = ethernet

 ==

 Copyright (c) 1992-2005 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 6.0-RELEASE #0: Fri Nov 11 17:00:05 UTC 2005
 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SPIRIT
 ACPI APIC Table: GBTAWRDACPI
 Timecounter i8254 frequency 1193182 Hz quality 0
 CPU: Intel(R) Celeron(R) CPU 1.70GHz (1962.60-MHz 686-class CPU)
   Origin = GenuineIntel  Id = 0xf13  Stepping = 3
   
Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS
,
 HTT,TM
 real memory  = 535756800 (510 MB)
 avail memory = 514940928 (491 MB)
 ioapic0 Version 2.0 irqs 0-23 on motherboard
 npx0: [FAST]
 npx0: math processor on 

Re: CF card and /dev filesystem entries

2005-11-20 Thread Robert Marella
On Sun, 20 Nov 2005 21:04:59 +
Brian Candler [EMAIL PROTECTED] wrote:

 On Wed, Nov 16, 2005 at 05:57:12PM +0100, Roland Smith wrote:
   However, when I insert a CF card with normal partioning I
   need /dev/da0s1, and this is not present in the /dev filesystem
   because the partition table has not been read.
  snip
   The only way I can see to *force* the superblock to be read is to
   attempt to mount the whole device as if it were unpartitioned.
   This is sufficient to cause the /dev/da0s1 entry to appear in
   the /dev filesystem.
  snip
   At this point, everything works as expected.
   
   My question is: is there an easier or more direct way to cause
   the partition table of the CF card to be read and the /dev
   filesystem to update?
  
  Try 'camcontrol rescan all' (as root).
 
 No joy.
 
 [EMAIL PROTECTED] brian# ls /dev/da0*
 /dev/da0
 [EMAIL PROTECTED] brian# camcontrol rescan all
 Re-scan of bus 0 was successful
 Re-scan of bus 1 was successful
 Re-scan of bus 2 was successful
 Re-scan of bus 3 was successful
 [EMAIL PROTECTED] brian# ls /dev/da0*
 /dev/da0
 
 Another suggestion was:
 
  I think devfs is updated when a descriptor on the device
  which was opended for writing is closed.  But you don't
  actually have to write anything.  That means, the following
  command should do it:
  
  # dd if=/dev/null of=/dev/da0 count=0
 
 Now, that does the job:
 
 [EMAIL PROTECTED] brian# dd if=/dev/null of=/dev/da0 count=0
 0+0 records in
 0+0 records out
 0 bytes transferred in 0.28 secs (0 bytes/sec)
 [EMAIL PROTECTED] brian# ls -l /dev/da0*
 crw-r-  1 root  operator0, 107 Nov 20 21:00 /dev/da0
 crw-r-  1 root  operator0, 115 Nov 20 21:00 /dev/da0s1
 [EMAIL PROTECTED] brian# 
 
 However, I'm not sure I actually *like* opening my CF card in such a
 way that I would be likely to overwrite the partition table if I hit
 a wrong key...
 
 Regards,
 
 Brian.

I am not sure if this is any different but when placing or changing a
card in my card reader I run  cat /dev/null  /dev/daX before
mounting. I have cards of different sizes and it would fail to mount a
different size card without doing the above first.

Good Luck
Robert
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]


6.0 Release - Pentium install panic and some questions

2005-11-20 Thread Paul Koch
Hi, we are having a number of issues with 6.0-Release.

Our setup: We have ~40 machines in a development test environment, 
ranging from P5/150Mhz/32M ram/IDE,  PII Celerons, P3, P4, single and 
dual processor setups.


Issue 1: Can't install on a Pentium P5 class machine:

The install panics when installing the base stuff. No useful messages 
are displayed accept the panic: page fault and rebooting in 15 
seconds. The machines are 10 year old DEC Pentiums, 32 to 64M ram, IDE 
disks, etc. We have four of these in our test environment and appear to 
install and run FreeBSD-5.4 fine.


Issue 2: phys_avail[] array too small in i386/machdep.c P5 boxes ??

We have something which we call a Remote Network Appliance (RNA), which 
is basically a boot floppy with lots of stuff squeezed on it. The RNA 
uses a cut down kernel config (ie. no kernel source modifications), 
various other inhouse programs (eg. init/inetd/telnetd replacements), 
built into a 1Mbyte MD root. We have no problems using everything up 
until a 5.4-stable kernel but have various problems with 6.0-release.  
When using 6.0, we get the following messages:

Overlapping or non-montonic memory region, ignoring second region
...
Too many holes in the physical address space, giving up
...
Fatel trap 12: page fault while in kernel mode
...
panic

Did a bit of searching and found that in Dragonfly phys_avail[] in 
i386/machdep.c has been bumped up because it is too small. Looking at 
6.0 machdep.c, looks like new dcons stuff has been added to it, and it 
blocks out some physical memory to use. Not sure if that has anything 
to do with it.  From my understanding, phys_avail[10] gives you room 
for four physical available address ranges (ie. 4 * start/end pair 
entries and null terminated).  I bumped the number up to 12 (ie. gives 
me five address ranges) and we are off and going.

6.0 now boots on all our Pentium machines, but...

on 5.4-stable we got:
 physical memory: 67108864
 avail memory:56156160

on 6.0 with phys_avail[12] we got:
 physical memory: 67108864
 avail memory:63299584

more available memory for some reason !  Hmmm.

On most of our machines, when booting in verbose mode, the 5.4 kernel 
reports three phys_avail segments, but the Pentium boxes report four. 
On the patched 6.0, the Pentiums report five segments.

Unfortunately, the machine panics on Pentium machines when stress 
testing it (ie. by making it run out of memory).  On 5.4-stable it 
would just kill user processes, under 6.0 it kills a few processes but 
quickly panics with a page not present error.  At least 6.0 now boots 
and runs on a Pentium, whereas the standard install panics.  I can't 
get a dump of the RNA floppy panic because it has no swap or disk to 
write to, and there isn't enough room on the floppy to build a kernel 
with debugging stuff.

So, my question is... is it OK to bump phys_avail from 10 to 12 ?? or do 
we just ditch the Pentium as a supported platform ?
Dragonfly have bumped it to 22, giving 10 segments.

The only other change we do is compile the kernel and world with -Os and 
-funit-at-a-time to reduce the resulting binary sizes.

fyi, A copy of the floppy image is at:
  http://www.statseeker.com/downloads/lanstat_fbsd60.bin
It also contains our realtime Statistical LAN Analyser. Instructions are 
at http://www.statseeker.com/download1.html


The following is the RNA kernel config:

hints   ./device.hints
machine i386
cpu I586_CPU
cpu I686_CPU
ident   RNA_KERNEL
options SCHED_ULE
options INET
options FFS
options MD_ROOT
options MD_ROOT_SIZE=1024
options COMPAT_FREEBSD4
options HZ=1000
options CLK_USE_I8254_CALIBRATION
options VM_KMEM_SIZE_SCALE
options NO_SWAPPING
options INIT_PATH=/rna-init

device  apm
device  pci
device  vga
device  fdc
device  md
device  mem
nodeviceio
device  atkbdc
device  atkbd
device  pty
device  sc
options MAXCONS=2
options SC_HISTORY_SIZE=500
options SC_NORM_ATTR=(FG_GREEN|BG_BLACK)
options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN)
options SC_KERNEL_CONS_ATTR=(FG_YELLOW|BG_BLACK)
options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED)
options SC_NO_CUTPASTE
options SC_NO_FONT_LOADING
options SC_NO_SYSMOUSE

options DEVICE_POLLING

device  de
device  em
device  ixgb
device  txp

device  miibus
device  bfe
device  bge
device  dc
device  fxp
device  lge
device  nge
device  pcn
device  re

device  sf
device  sis
device  sk
device  ste
device  ti
device  tl
device  tx
device  vge
device  vr
device  wb
device  xl

device  loop
device  

acpi_perf error

2005-11-20 Thread Zoran Kolic
Hi all!
I've seen this error some 300 times
at the beginning of boot process.
System goes up and works with no issue.
It is nforce3 250 with amd64, 6.0 os.
Using sysctl, I've found the line:
dev.acpi_perf.0.%driver: acpi_perf
In bios acpi apic is turned off, due to
acpi errors from 5.4 era. Kernel includes
cpufreq and powerd is in rc.conf.
Is there any known command for sysctl
to change driver? Or should I put
apic back?
Would be nice to have temperature reading
on this mobo to compare cpufreq effect.
Best regards

  Zoran

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