from:"Harald Schmalzbauer"

 Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
 …
 The problem I reported about in the first place is triggered by a faulty 
 loader.efi that
 arises, when optimisation level is -O3. -O2 works fine.

I can confirm that this problem also shows up when using
'CPUTYPE?=core-avx2'
Setting CPUTYPE to core-avx-i doesnt ehibit the problem.

I could narrow down the cause to libefi.a (sys/boot/efi).
But I don't understand the things going on there, so no clue how to fix
besides maybe

--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
@@ -2,6 +2,10 @@

BINDIR?= /boot

+.ifdef CPUTYPE
+.undef CPUTYPE
+.endif
+
.if ${MACHINE_CPUARCH} == i386
CFLAGS+= -march=i386
.endif

-Harry



signature.asc
Description: OpenPGP digital signature

Re: CURRENT: EFI boot failure

 Bezüglich Harald Schmalzbauer's Nachricht vom 23.09.2014 16:28
(localtime):
  Bezüglich O. Hartmann's Nachricht vom 19.09.2014 15:22 (localtime):
 …
 The problem I reported about in the first place is triggered by a faulty 
 loader.efi that
 arises, when optimisation level is -O3. -O2 works fine.
 I can confirm that this problem also shows up when using
 'CPUTYPE?=core-avx2'
 Setting CPUTYPE to core-avx-i doesnt ehibit the problem.

 I could narrow down the cause to libefi.a (sys/boot/efi).
 But I don't understand the things going on there, so no clue how to fix
 besides maybe

 --- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
 +++ sys/boot/efi/Makefile.inc 2014-09-23 16:25:16.0 +0200
 @@ -2,6 +2,10 @@

 BINDIR?= /boot

 +.ifdef CPUTYPE
 +.undef CPUTYPE
 +.endif

Sorry, forget the suggestion, it doesn't work since it leads to CFLAG
-march= and the same problem occurs.
For my case this works:
--- sys/boot/efi/Makefile.inc.orig  2014-09-23 16:22:46.0 +0200
+++ sys/boot/efi/Makefile.inc   2014-09-23 16:46:30.0 +0200
@@ -2,6 +2,10 @@
 
 BINDIR?=   /boot
 
+.if ${CPUTYPE} == core-avx2
+CPUTYPE=   core-avx-i
+.endif
+
 .if ${MACHINE_CPUARCH} == i386
 CFLAGS+=-march=i386
 .endif

JFI

-Harry



signature.asc
Description: OpenPGP digital signature

Re: /boot/loader.efi and buildkernel

 Bezüglich O. Hartmann's Nachricht vom 23.09.2014 14:16 (localtime):
 Modules and kernel are built when running make buildkernel, but the other 
 contents
 of /boot/ aren't. How can I manually - and separately - build the loader,
 especially /boot/loader.efi?

Simply cd to src/sys/boot and do 'make clean  make  make
DESTDIR=/altroot', the latter only if you don't want to overwrite
curdev's /boot/ files.
For loader.efi only, it's enough to do 'make clean  make' in the
following directories:
src/sys/boot/ficl
src/sys/boot/efi
src/sys/boot/amd64/efi

From amd64/efi you can 'make install' to just copy loader.efi (or copy
manually from obj/$src/sys/boot/amd64/efi/loader.efi)


 I realized that building loader.efi with any kind of optimization beyond 
 debugging- or
 close-to-debugging level ends up in an unloadable loader.efi on Haswell CPUs 
 (IvyBridge
 and C2D seem to be unaffected). The system in question is the most recent 
 CURRENT,
 compiled with system's CLANG 3.4.1.

This is confirmed for CPUTYPE=core-avx2, see my recent post. My test
machine was haswell as well, but I haven't tested on anything else!

-Harry




signature.asc
Description: OpenPGP digital signature

Re: CURRENT: EFI boot failure

 Bezüglich Nathan Whitehorn's Nachricht vom 23.09.2014 17:00 (localtime):
 Could you try adding -mno-avx2 to /sys/boot/amd64/Makefile.inc line 9? 

Done so, but it doesn't fix the problem with halting loader.efi when
compiled with CPUTYPE=core-avx2.

The whole -mno-xyz isn't applied to sys/boot/efi/libefi:
cc  -O2 -pipe -march=core-avx2  -fPIC
-I/usr/src/sys/boot/efi/libefi/../include
-I/usr/src/sys/boot/efi/libefi/../include/amd64
-I/usr/src/sys/boot/efi/libefi/../../../../lib/libstand
-I/usr/src/sys/boot/efi/libefi/../../common -DNO_PCI -fformat-extensions
-ffreestanding -fshort-wchar -Wformat -std=gnu99-Qunused-arguments
-c delay.c -o delay.o

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))

2014-08-22 Thread Harald Schmalzbauer

 Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime):
 Please check in this patch:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=181741
 Please MFC into 9.X

 Description of the problem is within PR.

 Thanks,
 Yuri

Hello,

I guess this fix should make it into 10.1.
Can someone check please?

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: nscd not caching

2014-08-19 Thread Harald Schmalzbauer

 Bezüglich Peter Wemm's Nachricht vom 17.08.2014 19:18 (localtime):
 On Sunday 17 August 2014 15:22:02 O. Hartmann wrote:
 Am Sun, 17 Aug 2014 13:09:10 +

 Eggert, Lars l...@netapp.com schrieb:
 Nobody using nscd? Really?
 I can only speak for myself and I stopped using nscd since the support is
 crap.

 A while ago (t  1 1/2 years) I realised within a OpenLDAP environment, that
 when nscd is running, sometimes the system simple forgets about root -
 this is painful while installing/updating ports and getting interrupted
 with a weird error unknown user root.

 nscd is supposed to be used in large environments where the cost for a user
 lookup, like in OpenLDAP, is worse. But obviously FreeBSD isn't used in
 that large environments with OpenLDAP and I'm wondering what the purpose of
 nscd is.
 The other problem is that net/nss_ldap and security/pam_ldap have kind of 
 been 
 left behind for performance and robustness.  People who use this seriousy 
 tend 
 to discover net/nss-pam-ldapd fairly quickly which has its own caching proxy 
 and eliminates the need for nscd.

 With nss_ldap and pam_ldap, the openldap client libraries and startup cost is 
 linked into every single binary that uses it.

 WIth pam-nss-ldapd, it's a simple unix domain socket (with peercred 
 authentication) and no heavy-weight libraries in the consumers. The proxy on 
 the other end of the socket keeps a ldap connection open (with an idle 
 timeout).  The whole thing was vastly more robust and efficient.

 At least that's what we found in the freebsd.org cluster.  nss-pam-ldapd was 
 two or three orders of magnitude more usable and got rid of nscd in the 
 process.

 For us, nscd worked, but it just didn't save much effort because it was a 
 per-uid cache.  ie: if jkh had just caused a ldap search, and peter 
 repeated it, it had to be done again from scratch.

 The downside for nss-pam-ldapd was that it uses a non-extensible wire 
 protocol 
 and didn't have room for bsd-style login classes.

This exactly refelcts my experiences too, which is why I'm wondering if
net/nss-pam-ldapd is a serious base candidate.
When nscd showed up (arround 7.0-Release if I remember correctly), it
was a big and highly appreciated improovement for me, reducing
interactivity lags of gnome e.g. by at least a factor of 4 for usual
desktop user tasks when user database was LDAP driven.
At that time there were rumors that FreeBSD needs LDAP user-database
support, but with the glitches of net/nss_ldap, it seemed that there's
no ready-to-implement solution at that time.
Things changed completely with net/nss-pam-ldapd. Haven't had any
negative experiences with single-LDAP backend networks. Haven't had big
environments yet either, but I think it's time to think about
base-LDAP-support again. net/nss-pam-ldapd is GPL licensed, so I guess
it won't get into base, but it was a great template, is it?

-Harry





signature.asc
Description: OpenPGP digital signature

Re: nscd not caching

2014-08-19 Thread Harald Schmalzbauer

 Bezüglich Eric van Gyzen's Nachricht vom 19.08.2014 15:39 (localtime):
 On 08/19/2014 09:14, Harald Schmalzbauer wrote:
  …
 At least that's what we found in the freebsd.org cluster.  nss-pam-ldapd 
 was 
 two or three orders of magnitude more usable and got rid of nscd in the 
 process.

 For us, nscd worked, but it just didn't save much effort because it was a 
 per-uid cache.  ie: if jkh had just caused a ldap search, and peter 
 repeated it, it had to be done again from scratch.

 The downside for nss-pam-ldapd was that it uses a non-extensible wire 
 protocol 
 and didn't have room for bsd-style login classes.
 This exactly refelcts my experiences too, which is why I'm wondering if
 net/nss-pam-ldapd is a serious base candidate.
 When nscd showed up (arround 7.0-Release if I remember correctly), it
 was a big and highly appreciated improovement for me, reducing
 interactivity lags of gnome e.g. by at least a factor of 4 for usual
 desktop user tasks when user database was LDAP driven.
 At that time there were rumors that FreeBSD needs LDAP user-database
 support, but with the glitches of net/nss_ldap, it seemed that there's
 no ready-to-implement solution at that time.
 Things changed completely with net/nss-pam-ldapd. Haven't had any
 negative experiences with single-LDAP backend networks. Haven't had big
 environments yet either, but I think it's time to think about
 base-LDAP-support again. net/nss-pam-ldapd is GPL licensed, so I guess
 it won't get into base, but it was a great template, is it?
 +1 for nss-pam-ldapd.  We were using nss_ldap+pam_ldap, but switched to
 nss-pam-ldapd.  It's much faster and very reliable.  We have several
 multi-user FreeBSD systems (build servers, doing lots of lookups),
 dozens of concurrent users and hundreds of total users, and Active
 Directory servers.

 The way nss_ldap links the LDAP libraries into every process is not just
 inefficient: it can be fatal.  Thunderbird includes (or formerly
 included?) its own private LDAP libraries.  These conflicted with those
 used by nss_ldap, so that Thunderbird would often crash.  I don't know
 if this is still a problem, but it's not /my/ problem anymore.

 As for the base system, pkg install nss-pam-ldapd is embarrassingly
 easy and /much/ easier than adding to the base system.

'pkg install' is incredibly convenient these days, for sure, but in my
world, hosts that don't need internet acces don't have internet access
(4 out of 5).
To make things worse, nfs exports aren't root-mapped (other than the
default nobody:nobody), so I quiet often have the case that I have to
provide net/nss-pam-ldapd via ISO-9660 image (for VMguests) or CD-media.
That's not so convenient.

Another limitation of 'pkg install' is that I can't influence what to
install. Sometimes I want nss_ldap without pam_ldap. Therefore I'd need
a compiler (somthing my production machines don't have) and ports, which
in my case can't be fetched from internet nor from the NFS server (the
latter has to be entered as LDAP user…)

That's why I'd love to see base system LDAP support – I think it's very
important to be able to setup a network computer in networks, which
aren't interconnected with other networks/internet; these days more
important ever since possible…

-Harry





signature.asc
Description: OpenPGP digital signature

Re: r268621: panic: shadowed tmpfs v_object [with dump]

2014-08-12 Thread Harald Schmalzbauer

 Bezüglich Sergey V. Dyatko's Nachricht vom 25.07.2014 07:36 (localtime):
 On Wed, 23 Jul 2014 22:56:46 +0200
 Mattia Rossi mattia.rossi.m...@gmail.com wrote: 

 Got the same panic, is this fix getting committed? Or has it already 
 been committed?
 r269053

Great. But it's not MFCd yet. 10.1 needs this :-)

-Harry



signature.asc
Description: OpenPGP digital signature

zfs ARC behaviour, Bug 187594

2014-08-12 Thread Harald Schmalzbauer

 Hello,

according to several reports, Karl Denningers (reworked) patch improoves
the ARC memory-release behaviour a lot.
It's discussed here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594#c10

I guess many useres were happy if this patch would make it into 10.1.
But it isn't in -current yet.
Are there still any objections?

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: Feature request: sticky bit inheritance

2013-11-28 Thread Harald Schmalzbauer

 Bezüglich Julian Elischer's Nachricht vom 28.11.2013 01:05 (localtime):
 On 11/28/13, 12:17 AM, Harald Schmalzbauer wrote:
   Bezüglich Julian Elischer's Nachricht vom 27.11.2013 16:20
 (localtime):
 On 11/27/13, 8:03 PM, Harald Schmalzbauer wrote:
Hello,

 ever since I took a FreeBSD machine into production, acting as any
 kind
 of file server, I have to work arround the problem, that write
 access to
 a directory implies unlinking (deleting) directory contents.
 not sure I fully understand what you mean by that..
 Do you mean write access implies delete access? yes..

 This can be modified with the nounlink flag.
 The uunlink flags also prohibits the owner to delete his files as far as
 I know. I want to prohibt users from deleting “foreign” files, even if
 the user has write access to the parent directory (and I wanted to
 explain that I don't understand why anybody would want that a user with
 write access to a directory can delete files on which the user doesn't
 have write access).

 You can always unlink a file that is not yours if you own the directory.
 because the ability to unlink is purely dependent on the directory.
 You don't change the file, and it may in fact have other links

I have an idea why this kind of permission ist default: It's more
expensive to extra check the file permission copmpared to only check the
directory permission, the only part which will be altered any way. I
guess having the sticky bit set by default would cause extra I/O+check,
which might have been too expensive in the past… So the default was to
do as less work as needed?!?


...
 I'd need every child directory of directories, who have the sticky bit
 set, also to have the sticky bit. The same behaviour as with the gid –
 it's the same as the parent has for new directories.
 patches accepted :-)

Besides horrible C skills, I have no idea where and how to start :-(
I hoped somebody else with deeper knowledge is also suffering badly and
someone could at least estimate the effort (in hours) needed to
implement a inhert-stickybit kernconf option, or even better, a sysctl.
Maybe I can pay for it.

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Feature request: sticky bit inheritance

2013-11-27 Thread Harald Schmalzbauer

 Hello,

ever since I took a FreeBSD machine into production, acting as any kind
of file server, I have to work arround the problem, that write access to
a directory implies unlinking (deleting) directory contents. Never heard
any sensible explanation why anybody would ever want that behaviour, but
it's been like that for decades and everybody seems to be fine with
that!?! Maybe because there's the stick bit, which is a usable workarround.
Unfortunately, there's no “sticky” equivalent in nfs4acls.
More unfortunate, newly created directories don't inherit the sticky bit
– unlike the group settings.
And most unfortunate, I'm not able to implement sticky bit inheritance
myself :-(

Since there's already a kind of inheritance when calling mkdir(1), I
guess extendig the inheritance to respect the sticky bit shouldn't be
too complex, is it?
I'd love to see a sysctl which controls the behaviour, so there's no
unexpected behaviour, but the possibillity to make FreeBSDs
filsystem-permission-control more real-world-usable. But if a sysctl is
noticable more effort than just a kern-conf (compile time) option, I'd
also highly appreciate that option!

Is there anybody who might want to look into that?

Thanks,

-Harry






signature.asc
Description: OpenPGP digital signature

Re: Feature request: sticky bit inheritance

2013-11-27 Thread Harald Schmalzbauer

 Bezüglich Julian Elischer's Nachricht vom 27.11.2013 16:20 (localtime):
 On 11/27/13, 8:03 PM, Harald Schmalzbauer wrote:
   Hello,

 ever since I took a FreeBSD machine into production, acting as any kind
 of file server, I have to work arround the problem, that write access to
 a directory implies unlinking (deleting) directory contents.
 not sure I fully understand what you mean by that..
 Do you mean write access implies delete access? yes..

 This can be modified with the nounlink flag.

The uunlink flags also prohibits the owner to delete his files as far as
I know. I want to prohibt users from deleting “foreign” files, even if
the user has write access to the parent directory (and I wanted to
explain that I don't understand why anybody would want that a user with
write access to a directory can delete files on which the user doesn't
have write access).
The sticky bit exactly does what I need (and should be the default
behaviour in my opinion).
But my problem is that the stick bit must be added to each single
directory after creation, it's not inherited.
I'd need every child directory of directories, who have the sticky bit
set, also to have the sticky bit. The same behaviour as with the gid –
it's the same as the parent has for new directories.

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: New iSCSI stack.

2013-10-30 Thread Harald Schmalzbauer

 Bezüglich Edward Tomasz Napierała's Nachricht vom 11.09.2013 23:14
(localtime):
 I'm working on last few minor nits to get this into the tree.  Give me few 
 days,
 I'll prepare a patch against 9-STABLE.

Hello,

I was highly interested in testing the new iscsi stack with 9-stable.
Could you prepare a patchset?

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

HW fed /dev/random

2013-09-10 Thread Harald Schmalzbauer

 Hello,

some time ago, before random(4) was rewritten for FreeBSD 5 by Mark
Murray, we had rng, the i815 hardware random number generator.
At this time, there were rumors about the quality of the randomness.

Now we have rdrand (BullMountain hardware random generator in IvyBridge)
and Dual_EC_DRBG (NSA's NIST contribution) makes me wonder if quality is
again something to worry about - although kib's commit message states:
„From the Intel whitepapers and articles about Bull Mountain, it seems
that we do not need to perform post-processing of RDRAND results, like
AES-encryption of the data with random IV and keys, which was done for
Padlock. Intel claims that sanitization is performed in hardware.“

When we use the software random device, one has great control over
/dev/random with sysctk kern.random.
Are there considerations to extend the HW-rng-implementation by optional
post processing?

-Harry





signature.asc
Description: OpenPGP digital signature

Re: [CFT] VMware vmxnet3 ethernet driver

2013-08-27 Thread Harald Schmalzbauer

 Bezüglich Bryan Venteicher's Nachricht vom 27.08.2013 06:18 (localtime):

...

 It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get
 »vmx0: cannot populate Rx queue 0«, I have no problems using jumbo
 frames with vmxnet3.

 This could fail for two reasons - could not allocate an mbuf cluster,
 or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you
 should check vmstat -z. For the later, the behavior of 
 bus_dmamap_load_mbuf_sg()
 changed between 9.1 and 9.2, and I know it was broken for awhile. I don't
 recall exactly when I fixed it (I think shortly after I made the original
 announcement). Could you retry with the files from HEAD @ [1]? Also, there
 are new sysctl oids (dev.vmx.X.mbuf_load_failed  dev.vmx.X.mgetcl_failed)
 for these errors.

 I just compiled the driver on 9.2-RC2 with the sources from HEAD and was
 able to change the MTU to 9000.

 [1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/

Thanks a lot for your ongoing work!
I can confirm that with recent if_vmx.c from head and compiled for
9.2-RC3, setting mtu to 9000 works as expected :-)


 I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi
 5.1U1 and FreeBSD-9.2-RC2
 Two guests are connected to one MTU9000 VMware Software Switch.

 I've got a few performance things to still look at. What's the sysctl 
 dev.vmx.X output for the if_vmx-if_vmx tests?

Just repeated if_vmx simple iperf bench, results vary slightly from
standard 10sec run to run, but still noticable high Intr usage:

if_vmx - if_vmx
1.32 GBits/sec, load: 10-45%Sys 40-48%Intr

if_vmxJumbo - if_vmxJumbo
5.01 GBits/sec, load: 10-45%Sys 40-48%Intr

Please find attached the different outputs of dev.vmx.X (the mtu9000 run was 
only 3.47GBits/sec in that case, took the numbers anyway)

wbr,

-Harry

dev.vmx.0.%desc: VMware VMXNET3 Ethernet Adapter
dev.vmx.0.%driver: vmx
dev.vmx.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PE40.S1F0
dev.vmx.0.%pnpinfo: vendor=0x15ad device=0x07b0 subvendor=0x15ad 
subdevice=0x07b0 class=0x02
dev.vmx.0.%parent: pci3
dev.vmx.0.ntxqueues: 1
dev.vmx.0.nrxqueues: 1
dev.vmx.0.collapsed: 0
dev.vmx.0.mgetcl_failed: 0
dev.vmx.0.mbuf_load_failed: 0
dev.vmx.0.txq0.ringfull: 133479
dev.vmx.0.txq0.offload_failed: 0
dev.vmx.0.txq0.hstats.tso_packets: 564986
dev.vmx.0.txq0.hstats.tso_bytes: 1686184580
dev.vmx.0.txq0.hstats.ucast_packets: 570604
dev.vmx.0.txq0.hstats.unicast_bytes: 1694679608
dev.vmx.0.txq0.hstats.mcast_packets: 0
dev.vmx.0.txq0.hstats.mcast_bytes: 0
dev.vmx.0.txq0.hstats.error: 0
dev.vmx.0.txq0.hstats.discard: 0
dev.vmx.0.txq0.debug.cmd_head: 106
dev.vmx.0.txq0.debug.cmd_next: 106
dev.vmx.0.txq0.debug.cmd_ndesc: 512
dev.vmx.0.txq0.debug.cmd_gen: 0
dev.vmx.0.txq0.debug.comp_next: 238
dev.vmx.0.txq0.debug.comp_ndesc: 512
dev.vmx.0.txq0.debug.comp_gen: 1
dev.vmx.0.rxq0.hstats.lro_packets: 0
dev.vmx.0.rxq0.hstats.lro_bytes: 0
dev.vmx.0.rxq0.hstats.ucast_packets: 579137
dev.vmx.0.rxq0.hstats.unicast_bytes: 38409312
dev.vmx.0.rxq0.hstats.mcast_packets: 0
dev.vmx.0.rxq0.hstats.mcast_bytes: 0
dev.vmx.0.rxq0.hstats.bcast_packets: 29
dev.vmx.0.rxq0.hstats.bcast_bytes: 1740
dev.vmx.0.rxq0.hstats.nobuffer: 0
dev.vmx.0.rxq0.hstats.error: 0
dev.vmx.0.rxq0.debug.cmd0_fill: 94
dev.vmx.0.rxq0.debug.cmd0_ndesc: 256
dev.vmx.0.rxq0.debug.cmd0_gen: 0
dev.vmx.0.rxq0.debug.cmd1_fill: 0
dev.vmx.0.rxq0.debug.cmd1_ndesc: 256
dev.vmx.0.rxq0.debug.cmd1_gen: 0
dev.vmx.0.rxq0.debug.comp_next: 94
dev.vmx.0.rxq0.debug.comp_ndesc: 512
dev.vmx.0.rxq0.debug.comp_gen: 0
dev.vmx.0.%desc: VMware VMXNET3 Ethernet Adapter
dev.vmx.0.%driver: vmx
dev.vmx.0.%location: slot=0 function=0 handle=\_SB_.PCI0.PE40.S1F0
dev.vmx.0.%pnpinfo: vendor=0x15ad device=0x07b0 subvendor=0x15ad 
subdevice=0x07b0 class=0x02
dev.vmx.0.%parent: pci3
dev.vmx.0.ntxqueues: 1
dev.vmx.0.nrxqueues: 1
dev.vmx.0.collapsed: 0
dev.vmx.0.mgetcl_failed: 0
dev.vmx.0.mbuf_load_failed: 0
dev.vmx.0.txq0.ringfull: 58950
dev.vmx.0.txq0.offload_failed: 0
dev.vmx.0.txq0.hstats.tso_packets: 230508
dev.vmx.0.txq0.hstats.tso_bytes: 4314020112
dev.vmx.0.txq0.hstats.ucast_packets: 235382
dev.vmx.0.txq0.hstats.unicast_bytes: 4356943552
dev.vmx.0.txq0.hstats.mcast_packets: 0
dev.vmx.0.txq0.hstats.mcast_bytes: 0
dev.vmx.0.txq0.hstats.error: 0
dev.vmx.0.txq0.hstats.discard: 0
dev.vmx.0.txq0.debug.cmd_head: 333
dev.vmx.0.txq0.debug.cmd_next: 333
dev.vmx.0.txq0.debug.cmd_ndesc: 512
dev.vmx.0.txq0.debug.cmd_gen: 0
dev.vmx.0.txq0.debug.comp_next: 376
dev.vmx.0.txq0.debug.comp_ndesc: 512
dev.vmx.0.txq0.debug.comp_gen: 0
dev.vmx.0.rxq0.hstats.lro_packets: 0
dev.vmx.0.rxq0.hstats.lro_bytes: 0
dev.vmx.0.rxq0.hstats.ucast_packets: 255918
dev.vmx.0.rxq0.hstats.unicast_bytes: 17043918
dev.vmx.0.rxq0.hstats.mcast_packets: 0
dev.vmx.0.rxq0.hstats.mcast_bytes: 0
dev.vmx.0.rxq0.hstats.bcast_packets: 15
dev.vmx.0.rxq0.hstats.bcast_bytes: 900
dev.vmx.0.rxq0.hstats.nobuffer: 0
dev.vmx.0.rxq0.hstats.error: 0
dev.vmx.0.rxq0.debug.cmd0_fill: 121

Re: [CFT] VMware vmxnet3 ethernet driver

2013-08-21 Thread Harald Schmalzbauer

 Bezüglich Bryan Venteicher's Nachricht vom 05.08.2013 02:12 (localtime):
 Hi,

 I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a
 lot of cleanup, bug fixes, new features, etc (+2000 new lines) along
 the way so there is not much of a resemblance left.

 The driver is in good enough shape I'd like additional testers. A patch
 against -CURRENT is at [1]. Alternatively, the driver and a Makefile is
 at [2]; this should compile at least as far back as 9.1. I can look at
 8-STABLE if there is interest.

 Obviously, besides reports of 'it works', I'm interested performance vs
 the emulated e1000, and (for those using it) the VMware tools vmxnet3
 driver. Hopefully it is no worse :)

Hello Bryan,

thanks a lot for your hard work!

It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get
»vmx0: cannot populate Rx queue 0«, I have no problems using jumbo
frames with vmxnet3.

I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi
5.1U1 and FreeBSD-9.2-RC2
Two guests are connected to one MTU9000 VMware Software Switch.

Simple iperf (standard TCP) results:

vmxnet3jumbo - vmxnet3jumbo
5.3Gbits/sec, load: 40-60%Sys 0.5-2%Intr

vmxnet3 - vmxnet3
1.85 GBits/sec, load: 60-80%Sys 0-0.8%Intr


if_vmx - if_vmx
1.51 GBits/sec, load: 10-45%Sys 40-48%Intr
!!!
if_vmxjumbo - if_vmxjumbo not possible


if_em(e1000) - if_em(e1000)
1.23 GBits/sec, load: 80-60%Sys 0.5-8%Intr

if_em(e1000)jumbo - if_em(e1000)jumbo
2.27Gbits/sec, load: 40-30%Sys 0.5-5%Intr


if_igb(e1000e)junmbo - if_igb(e1000e)jumbo
5.03 Gbits/s, load: 70-60%Sys 0.5%Intr

if_igb(e1000e) - if_igb(e1000e)
1.39 Gbits/s, load: 60-80%Sys 0.5%Intr


f_igb(e1000e) - if_igb(e1000e), both hw.em.[rt]xd=4096
1.66 Gbits/s, load: 65-90%Sys 0.5%Intr

if_igb(e1000e)junmbo - if_igb(e1000e)jumbo, both hw.em.[rt]xd=4096
4.81 Gbits/s, load: 65%Sys 0.5%Intr

Conclusion:
if_vmx performs well compared to the regular emulated nics and standard
MTU, but it's behind tuned e1000e nic emulation and can't reach vmxnet3
performance with regular mtu. If one needs throughput, the missing jumbo
frame support in if_vmx  is a show stopper.

e1000e is preferable over e1000, even if not officially choosable with
FreeBSD-selection as guest (edit .vmx and alter ethernet0.virtualDev =
e1000e, and dont forget to set hw.em.enable_msix=0 in loader.conf,
although the driver e1000e attaches is if_igb!)

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: MPSAFE VFS -- List of upcoming actions

2013-08-08 Thread Harald Schmalzbauer

Bezüglich Kevin Oberman's Nachricht vom 08.08.2013 01:11 (localtime):
On Wed, Aug 7, 2013 at 11:04 AM, Harald Schmalzbauer
h.schmalzba...@omnilan.de wrote:

Bezüglich Attilio Rao's Nachricht vom 14.10.2012 02:27 (localtime):
On Fri, Sep 21, 2012 at 1:22 AM, Attilio Rao atti...@freebsd.org
wrote:
On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao atti...@freebsd.org
wrote:
On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao atti...@freebsd.org
wrote:
2012/7/4 Attilio Rao atti...@freebsd.org:
2012/6/29 Attilio Rao atti...@freebsd.org:
As already published several times, according to the following plan:
http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS

I still haven't heard from Vivien or Edward, anyway as NTFS is
basically only used RO these days (also the mount_ntfs code just
permits RO mounting) I stripped all the uncomplete/bogus write
support
with the following patch:
http://www.freebsd.org/~attilio/ntfs_remove_write.patch

This is an attempt to make the code smaller and possibly just focus
on

...

I've committed the FUSE support into base as r241519.
Thank you for your great work!
I had used
http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch
with releng/9.1.
Some improovements were made in the meantime in head.
I'm not familiar with svn.
Was it possible to generate a new patchset against releng/9.2? I'd have
to concat manually downloadad revisions via svnweb... :-(

Thanks a lot,

-Harry

Already done. All of the changes in head have been back-ported to
9.2-PRERELEASE with the exception of a locking enhancement not available
outside of current. You can find it at:
https://docs.google.com/file/d/0B9QNUQlebx5UdlhPUTB4TXF6enc/edit?usp=sharing

Great, I found accidentally the download-arrow for
fuse_stable9_253631.patch after enabling java script - not used to
google interfaces... (for those who want to get the patch with
fetch/wget/...:
ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/deploy-tools/local-patches/RELENG_9_2/no_autoapply/fuse_stable9_253631.patch.orig
)

There's still only GENERIC for amd64 altered to include fuse by default.
Any reason why not i386? I'd not include it in any GENERIC kernel, I'd
prefer keeping it loadable...

Just for interest, is there a one-liner to get such a patchset out of
svn? Looks like the above was done with local sourcetree, not svn
internally?

Best regards,

-Harry

signature.asc
Description: OpenPGP digital signature

Re: MPSAFE VFS -- List of upcoming actions

2013-08-07 Thread Harald Schmalzbauer

 Bezüglich Attilio Rao's Nachricht vom 14.10.2012 02:27 (localtime):
 On Fri, Sep 21, 2012 at 1:22 AM, Attilio Rao atti...@freebsd.org wrote:
 On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao atti...@freebsd.org wrote:
 On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao atti...@freebsd.org wrote:
 2012/7/4 Attilio Rao atti...@freebsd.org:
 2012/6/29 Attilio Rao atti...@freebsd.org:
 As already published several times, according to the following plan:
 http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS

 I still haven't heard from Vivien or Edward, anyway as NTFS is
 basically only used RO these days (also the mount_ntfs code just
 permits RO mounting) I stripped all the uncomplete/bogus write support
 with the following patch:
 http://www.freebsd.org/~attilio/ntfs_remove_write.patch

 This is an attempt to make the code smaller and possibly just focus on

...

 I've committed the FUSE support into base as r241519.

Thank you for your great work!
I had used
http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch
with releng/9.1.
Some improovements were made in the meantime in head.
I'm not familiar with svn.
Was it possible to generate a new patchset against releng/9.2? I'd have
to concat manually downloadad revisions via svnweb... :-(

Thanks a lot,

-Harry



signature.asc
Description: OpenPGP digital signature

patch to inherit sticky bit

2013-01-17 Thread Harald Schmalzbauer

 Dear developers,

I'm really missing the possibility to get the sticky bit inherited.
I'm using zfs these days, together with nfs4acls and it almost does
things like real world users expect.
I never understood why write permission to a directory allowes file
unlinking inside, even if the user has no write permission on that file...
With addidional acls, this is even worse.
One simple solution is the sticky bit. But I can't inherit it with nfs4acls.
How would a patch best accomplish that? Should mkdir respect the sticky
bit? How is current group inheritance with mkdir implemented?
I'd really need a sysctl or kernel compile option which enables sticky
bit inheritance.

Thanks for any help,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: [patch] permit fib to be set on interface

2012-12-19 Thread Harald Schmalzbauer

 schrieb Alexander V. Chernikov am 08.05.2011 15:09 (localtime):
 At the moment the only possible way to set packet fib from userland is
 ipfw(8) setfib rule. Since no 'setfib tablearg' exists ruleset grows
 with every fib.
 Additionally, there is no way to set packet fib before netgraph
 processing: L2 ipfw hook is called after ng_ether_input()

 Those reasons (not mentioning kern/134931) makes it hard to use multiple
 routing tables.

 The following path:
 * adds SIOCGIFIB/SIOCSIFIB ioctl(2) calls to get/set per-interface fib
 * adds IFF_CUSTOMFIB interface flags
 * adds ifi_fib field to if_data structure
 * adds 'fib' keyword for ifconfig(8)

 Example:
 16:42 [0] zfscurr0# ifconfig vlan2 create inet 10.11.12.13/30 fib 15
 vlan 2 vlandev em0
 16:42 [0] zfscurr0# ifconfig vlan2
 vlan2: flags=808843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,CUSTOMFIB
 metric 0 mtu 1500 fib 15
 options=3RXCSUM,TXCSUM
 ether 08:00:27:c5:29:d4
 inet 10.11.12.13 netmask 0xfffc broadcast 10.11.12.15
 inet6 fe80::a00:27ff:fec5:29d4%vlan2 prefixlen 64 scopeid 0x4
 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL
 media: Ethernet autoselect (1000baseT full-duplex)
 status: active
 vlan: 2 parent interface: em0


 Interface fib is applied on inbound only (for forwarded packets fib
 decision should be done on inbound, for locally-originated packets there
 is setfib(1))

Could you please help me understanding the design?
If I have a multihomed machine, with fib0 defaultrouter via nic0 and
fib1 defaultrouter via nic1, and nic1 has fib1 assigned.
What should happen if I connect to any service, by default assigned to
fib0, but passing nic1?
The incoming packet will be tagged with FIB1, right?
But does that affect the answer-path of services not assigned to fib1?
If not, why would I want incoming packates tagged?

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: Bull Mountain (IvyBridge +) random number generator

2012-10-13 Thread Harald Schmalzbauer

 schrieb Konstantin Belousov am 12.10.2012 18:48 (localtime):
 On Fri, Oct 12, 2012 at 10:50:55AM +0200, Harald Schmalzbauer wrote:
 ...
 Try the stable/9 instead. The code was merged in r240950.
 There was a bug in the original patch with the similar description.

Thanks, it seems to be working with r240950 for RELENG_9_1
(ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/deploy-tools/local-patches/RELENG_9_1/from_9-stable_branch/bull_mountain.patch).

dd if=/dev/random bs=1k count=1000 | ent
1000+0 records in
1000+0 records out
1024000 bytes transferred in 0.028026 secs (36537676 bytes/sec)
Entropy = 7.999827 bits per byte.

Optimum compression would reduce the size
of this 1024000 byte file by 0 percent.

Chi square distribution for 1024000 samples is 244.91, and randomly
would exceed this value 66.40 percent of the times.

Arithmetic mean value of data bytes is 127.6039 (127.5 = random).
Monte Carlo value for Pi is 3.139277888 (error 0.07 percent).
Serial correlation coefficient is -0.001852 (totally uncorrelated = 0.0).



I don't know if the requested verbose-boot-log is also of interest with
ESXi-Guest, in case I've attached it.

I think the man page answers my question how to find out (without
verbose_boot) what real rng is used for /dev/random.
If sysctl kern.random.sys is present, then it's sw rng, otherwise it's
hw-rng.
But random(4) needs to be uptdated:
The only hardware implementation currently is for the
 VIA C3 Nehemiah (stepping 3 or greater) CPU.  More will be added in the
 future

Also, long time ago we had support for i815 RNG. Back in December 2005,
Mark Murray planned to re-implement it...
Does anybod know if the chipset RNG was still available in decent hw?

Here's the throughput difference for bull mountain (in ESXi 5.1 guest):
 
With options RDRAND_RNG:
dd if=/dev/random of=/dev/null bs=1k count=10
10+0 records in
10+0 records out
10240 bytes transferred in 0.722204 secs (141788199 bytes/sec)

Without:
dd if=/dev/random of=/dev/null bs=1k count=10
10+0 records in
10+0 records out
10240 bytes transferred in 1.054229 secs (97132594 bytes/sec)


Thanks,

-Harry
Table 'FACP' at 0xbfefee98
Table 'BOOT' at 0xbfef01fc
Table 'APIC' at 0xbfef0182
APIC: Found table at 0xbfef0182
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 1: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 3: enabled
SMP: Added CPU 3 (AP)
Copyright (c) 1992-2012 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.1-RC2 #9 r241483M: Sat Oct 13 12:09:46 CEST 2012

ad...@gundi.vnl.wdn.omnilan.net:/usr/local/share/deploy-tools/obj-amd64/VMWARE/usr/local/share/deploy-tools/RELENG_9_1/src/sys/VMWARE.flint
 amd64
Preloaded elf kernel /boot/kernel/kernel at 0x80d6e000.
Preloaded elf obj module /boot/kernel/aesni.ko at 0x80d6e1f8.
Preloaded elf obj module /boot/kernel/mps.ko at 0x80d6e820.
Hypervisor: Origin = VMwareVMware
CPU: Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz (3492.07-MHz K8-class CPU)
  Origin = GenuineIntel  Id = 0x306a9  Family = 6  Model = 3a  Stepping = 9
  
Features=0x1fa3fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,DTS,MMX,FXSR,SSE,SSE2,SS,HTT
  
Features2=0xfeba2203SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV
  AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant
real memory  = 8589934592 (8192 MB)
Physical memory chunk(s):
0x1000 - 0x0009bfff, 634880 bytes (155 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x00da2000 - 0xbfed, 3205750784 bytes (782654 pages)
0xbff0 - 0xbfff, 1048576 bytes (256 pages)
0x0001 - 0x00022f11, 5084676096 bytes (1241376 pages)
avail memory = 8236912640 (7855 MB)
INTR: Adding local APIC 0 as a target
Event timer LAPIC quality 600
ACPI APIC Table: PTLTD  APIC  
INTR: Adding local APIC 0 as a target
INTR: Adding local APIC 1 as a target
INTR: Adding local APIC 2 as a target
INTR: Adding local APIC 3 as a target
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
APIC: CPU 0 has ACPI ID 0
APIC: CPU 1 has ACPI ID 1
APIC: CPU 2 has ACPI ID 2
APIC: CPU 3 has ACPI ID 3
x86bios:  IVT 0x00-0x0004ff at 0xfe00
x86bios: SSEG 0x001000-0x001fff at 0xff800023
x86bios: EBDA 0x09f000-0x09 at 0xfe09f000
x86bios:  ROM 0x0a-0x0fefff at 0xfe0a
ULE: setup cpu 0
ULE: setup

Re: Bull Mountain (IvyBridge +) random number generator

2012-10-12 Thread Harald Schmalzbauer

 schrieb Konstantin Belousov am 02.09.2012 12:34 (localtime):
 It is relatively well known that Ivy Bridge CPUs (Core iX 3XXX) have
 built-in hardware random number generator, which is claimed to be both
 very fast and high quality. Generator is accessible using non-privileged
 RDRAND instruction. It is claimed that CPU performs sanitization of the
 random sequence. In particular, it seems that paranoid AES encryption of
 the raw random stream, performed by our padlock driver, is not needed
 for Bull Mountain (there are hints that hardware performs it already).

 See
 http://spectrum.ieee.org/computing/hardware/behind-intels-new-randomnumber-generator/0
 http://software.intel.com/en-us/articles/intel-digital-random-number-generator-drng-software-implementation-guide/
 and IA32 ADM.

 Patch at
 http://people.freebsd.org/~kib/misc/bull_mountain.2.patch
 implements support for the generator. I do not own any IvyBridge machines,
 so I cannot test. Patch makes both padlock and bull generators the options,
 you need to enable IVY_RNG to get support for the generator.

 I would be interested in seeing reports including verbose boot dmesg,
 and some tests of /dev/random quality on the IvyBridge machines, you can
 start with 
 http://lists.gnupg.org/pipermail/gnupg-devel/2000-March/016328.html.

Thanks a lot for implementing this!
I have an ESXi host with Ivy Brindge CPU.
FreeBSD guest reports the following:
CPU: Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz (3492.07-MHz K8-class CPU)
  Origin = GenuineIntel  Id = 0x306a9  Family = 6  Model = 3a 
Stepping = 9
 
Features=0x1fa3fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,DTS,MMX,FXSR,SSE,SSE2,SS,HTT
 
Features2=0xfeba2203SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV
  AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM
  AMD Features2=0x1LAHF
  TSC: P-state invariant
real memory  = 8589934592 (8192 MB)
avail memory = 8235110400 (7853 MB)
Event timer LAPIC quality 600
ACPI APIC Table: PTLTD   APIC  
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 4 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
MADT: Forcing active-low polarity and level trigger for SCI

But unfortunately accessing /dev/random doesn't work with IVY_RNG enabled.
'dd' consumes 100% wcpu bound to one core but never finishes (dd
if=/dev/random bs=1k count=100|./ent)
Also some other functions are blocked, logging in for example (doesn't
matter if it's console or ssh). But I can walk arround in already
established sessions.

I made a 9.1-RC-2 debug kernel but no info appears. Also IVY_RNG isn't
reported after kldloading, nor during boot, but this is the expected
behaviour if I unterstand your patch correctly.

I guess using RDRAND in an hypervisor environment should make no
difference but please correct me if I'm wrong.

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: MPSAFE VFS -- List of upcoming actions

2012-09-28 Thread Harald Schmalzbauer

 schrieb Attilio Rao am 28.09.2012 16:18 (localtime):
 On Wed, Sep 26, 2012 at 12:02 PM, Harald Schmalzbauer
 h.schmalzba...@omnilan.de wrote:
  ...
 After many people willing to test fuse on STABLE_9, I made this patch
 that at least compiles there:
 http://www.freebsd.org/~attilio/fuse_import/fuse_stable9_241030.patch

Thanks a lot! In the meantime I made the original patch compiling. I
simply looked at the changes which were made around july in the fuse
project to follow changes in head (checkpath(), vrecycle() and
vtruncbuf()) and reverted them.
Since I have no idea about the code I modified, I'm happy that you did a
more qualified patch set :-)

 Of course, I didn't have a chance to test it because I'm also out for
 vacation right now but please do and report.

Happy holiday!!! If you're by chance arround the Oktoberfest, drop me a
note, I'll pay you a Maß (or any other drink if you don't like
„Wiesnbier“) :-)

 ...
 Some questions: Is this planned to be mfc'd and if so, how can one know?
 In which sense how can one know?. We usually specify MFC timeouts in
 the commit message (not sure if this answers your concerns).

Yep, that's what I wanted to know. So if there's no MFC timeout in the
log, it's not intended to be MFCd ever I guess.

Thanks a lot!
World/Kernel compiled fine in the meantime, I'll do some sshfs tests.

-Harry



signature.asc
Description: OpenPGP digital signature

Re: MPSAFE VFS -- List of upcoming actions

2012-09-26 Thread Harald Schmalzbauer

 schrieb Harald Schmalzbauer am 25.09.2012 20:24 (localtime):
  schrieb Attilio Rao am 21.09.2012 02:22 (localtime):
 On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao atti...@freebsd.org wrote:
 On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao atti...@freebsd.org wrote:
 2012/7/4 Attilio Rao atti...@freebsd.org:
 2012/6/29 Attilio Rao atti...@freebsd.org:
 As already published several times, according to the following plan:
 http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS

 I still haven't heard from Vivien or Edward, anyway as NTFS is
 basically only used RO these days (also the mount_ntfs code just
 permits RO mounting) I stripped all the uncomplete/bogus write support
 with the following patch:
 http://www.freebsd.org/~attilio/ntfs_remove_write.patch

 This is an attempt to make the code smaller and possibly just focus on
 the locking that really matter (as read-only filesystem).
 On some points of the patch I'm a bit less sure as we could easily
 take into account also write for things like vaccess() arguments, and
 make easier to re-add correct write support at some point in the
 future, but still force RO, even if the approach used in the patch is
 more correct IMHO.
 As an added bonus this patch cleans some dirty code in the mount
 operation and fixes a bug as vfs_mountedfrom() is called before real
 mounting is completed and can still fail.
 A quick update on this.
 It looks like NTFS won't be completed for this GSoC thus I seriously
 need to find an alternative to not loose the NTFS support entirely.

 I tried to look into the NTFS implementation right now and it is
 really a poor support. As Peter has also verified, it can deadlock in
 no-time, it compeltely violates VFS rules, etc. IMHO it deserves a
 complete rewrite if we would still support in-kernel NTFS. I also
 tried to look at the NetBSD implementation. Their code is someway
 similar to our, but they used very complicated (and very dirty) code
 to do the locking. Even if I don't know well enough NetBSD VFS, I have
 the impression not all the races are correctly handled. Definitively,
 not something I would like to port.

 Considering all that the only viable option would be meaning an
 userland filesystem implementation. My preferred choice would be to
 import PUFFS and librefuse on top of it but honestly it requires a lot
 of time to be completed, time which I don't currently have as in 2
 months Giant must be gone by the VFS.

 I then decided to switch to gnn's rewamp of FUSE patches. You can find
 his initial e-mail here:
 http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013876.html

 I've precisely got the second version of George's patch and created
 this dolphin branch:
 svn://svn.freebsd.org/base/projects/fuse

 I'm fixing low hanging fruit for the moment (see r238411 for example)
 and I still have to make a throughful review.
 However my idea is to commit the support once:
 - ntfs-3g is well stress-tested and proves to be bug-free
 - there is no major/big technical issue pending after the reviews
 In the last weeks Peter, Florian, Gustau and I have been working in
 stabilizing fuse support. In the specific, Peter has worked hard on
 producing several utilities to nit stress-test fuse and in particular
 ntfs, Florian has improved fuse related ports (as explained later) and
 Gustau has done sparse testing. I feel moderately satisfied by the
 level of stability of fuse now to propose to wider usage, in
 particular given the huge amount of complaints I'm hearing around
 about occasional fuse users.

 The final target of the project is to completely import into base the
 content of fusefs-kmod starting from earlier posted patches by George.
 So far, we took care only of importing in the fuse branch the kernel
 part, so that fusefs-kmod userland part is still needed to be
 installed from ports, but I was studying the mount_fusefs licensing
 before to process with the import for the userland bits of it.

 The fixing has been happening here:
 svn://svn.freebsd.org/base/projects/fuse/

 which is essentially an HEAD branch + fuse kernel components. In order
 to get fuse, please compile a kernel from this branch with FUSE option
 or simply build and load fuse module.
 Alternatively, a kernel patch that should work with HEAD@240684 is here:
 http://www.freebsd.org/~attilio/fuse_import/fuse_240684.patch

 I guess the patch can easilly apply to all FreeBSD branches, really,
 but it is not tested to anything else different then -CURRENT.

 As said you still need currently to build fusefs-kmod port. However
 you need these further patches, to be put in the fusefs-kmod/files/
 directory::
 http://www.freebsd.org/~attilio/fuse_import/patch-Makefile
 http://www.freebsd.org/~attilio/fuse_import/patch-mount_fusefs__mount_fusefs2.c

 They both disable the old kernel building/linking and import new
 functionality to let the new kernel support work well in presence of
 many consumers.

 In addition to fusefs-kmod, Bryan and Florian have also updated

Re: MPSAFE VFS -- List of upcoming actions

2012-09-25 Thread Harald Schmalzbauer

 schrieb Attilio Rao am 21.09.2012 02:22 (localtime):
 On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao atti...@freebsd.org wrote:
 On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao atti...@freebsd.org wrote:
 2012/7/4 Attilio Rao atti...@freebsd.org:
 2012/6/29 Attilio Rao atti...@freebsd.org:
 As already published several times, according to the following plan:
 http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS

 I still haven't heard from Vivien or Edward, anyway as NTFS is
 basically only used RO these days (also the mount_ntfs code just
 permits RO mounting) I stripped all the uncomplete/bogus write support
 with the following patch:
 http://www.freebsd.org/~attilio/ntfs_remove_write.patch

 This is an attempt to make the code smaller and possibly just focus on
 the locking that really matter (as read-only filesystem).
 On some points of the patch I'm a bit less sure as we could easily
 take into account also write for things like vaccess() arguments, and
 make easier to re-add correct write support at some point in the
 future, but still force RO, even if the approach used in the patch is
 more correct IMHO.
 As an added bonus this patch cleans some dirty code in the mount
 operation and fixes a bug as vfs_mountedfrom() is called before real
 mounting is completed and can still fail.
 A quick update on this.
 It looks like NTFS won't be completed for this GSoC thus I seriously
 need to find an alternative to not loose the NTFS support entirely.

 I tried to look into the NTFS implementation right now and it is
 really a poor support. As Peter has also verified, it can deadlock in
 no-time, it compeltely violates VFS rules, etc. IMHO it deserves a
 complete rewrite if we would still support in-kernel NTFS. I also
 tried to look at the NetBSD implementation. Their code is someway
 similar to our, but they used very complicated (and very dirty) code
 to do the locking. Even if I don't know well enough NetBSD VFS, I have
 the impression not all the races are correctly handled. Definitively,
 not something I would like to port.

 Considering all that the only viable option would be meaning an
 userland filesystem implementation. My preferred choice would be to
 import PUFFS and librefuse on top of it but honestly it requires a lot
 of time to be completed, time which I don't currently have as in 2
 months Giant must be gone by the VFS.

 I then decided to switch to gnn's rewamp of FUSE patches. You can find
 his initial e-mail here:
 http://lists.freebsd.org/pipermail/freebsd-fs/2012-March/013876.html

 I've precisely got the second version of George's patch and created
 this dolphin branch:
 svn://svn.freebsd.org/base/projects/fuse

 I'm fixing low hanging fruit for the moment (see r238411 for example)
 and I still have to make a throughful review.
 However my idea is to commit the support once:
 - ntfs-3g is well stress-tested and proves to be bug-free
 - there is no major/big technical issue pending after the reviews
 In the last weeks Peter, Florian, Gustau and I have been working in
 stabilizing fuse support. In the specific, Peter has worked hard on
 producing several utilities to nit stress-test fuse and in particular
 ntfs, Florian has improved fuse related ports (as explained later) and
 Gustau has done sparse testing. I feel moderately satisfied by the
 level of stability of fuse now to propose to wider usage, in
 particular given the huge amount of complaints I'm hearing around
 about occasional fuse users.

 The final target of the project is to completely import into base the
 content of fusefs-kmod starting from earlier posted patches by George.
 So far, we took care only of importing in the fuse branch the kernel
 part, so that fusefs-kmod userland part is still needed to be
 installed from ports, but I was studying the mount_fusefs licensing
 before to process with the import for the userland bits of it.

 The fixing has been happening here:
 svn://svn.freebsd.org/base/projects/fuse/

 which is essentially an HEAD branch + fuse kernel components. In order
 to get fuse, please compile a kernel from this branch with FUSE option
 or simply build and load fuse module.
 Alternatively, a kernel patch that should work with HEAD@240684 is here:
 http://www.freebsd.org/~attilio/fuse_import/fuse_240684.patch

 I guess the patch can easilly apply to all FreeBSD branches, really,
 but it is not tested to anything else different then -CURRENT.

 As said you still need currently to build fusefs-kmod port. However
 you need these further patches, to be put in the fusefs-kmod/files/
 directory::
 http://www.freebsd.org/~attilio/fuse_import/patch-Makefile
 http://www.freebsd.org/~attilio/fuse_import/patch-mount_fusefs__mount_fusefs2.c

 They both disable the old kernel building/linking and import new
 functionality to let the new kernel support work well in presence of
 many consumers.

 In addition to fusefs-kmod, Bryan and Florian have also updated
 fusefs-lib and fusefs-ntfs ports. For instance, please refer to

Idea for GEOM and policy based file encryption

2012-03-21 Thread Harald Schmalzbauer

 Hello,

I personally don't have the need to encrypt whole filesystems and if I
need to transfer sensitive data I use gpg to encrypt the tarball or
whatever.
But, I'd like to see some single files encrypted on my systems, eg.
wpasupplicant.conf, ipsec.conf aso.
Since I recently secured LDAP queries via IPSec, I found this to be the
absolute perfect solution. Encryption takes place only where really
needed with about no overhead (compared to SSL-LDAP)
So would it be imaginable, that there's something like the SPD for
network sockets also for files?
The idea is that in this fileSPD, there's the entry that /etc/ipsec.conf
must be aes encrypted. In a fileSA, there's the info that
/etc/ipsec.conf can be read by uid xyz (or only one specific kernel,
identified by something new to implement) and with a special key ID. The
keys are loadad as modules, optionally symmetric encrypted by passphrase.

Was such a policy based file encryption control doable with GEOM?
Maybe it's easier to make use of existing tools like gpg with GEOM
interaction?
I don't want to reinvent any file encryption, I just need some automatic
encryption (without _mandatory_ interaction) with lowest possible bypass
possibilities.

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: Effect of Processor and Memory on KDE4 execution speed

2012-02-15 Thread Harald Schmalzbauer

 schrieb Mehmet Erol Sanliturk am 14.02.2012 15:39 (localtime):
 Dear All ,

 Today I have encountered a case which I think informing you about it may be
 useful .

 In my previous messages , I have mentioned very slowness of KDE4 .


 Onto another computer I have installed DruidBSD 9.0 b56 amd64 , and KDE4 .
 In that installation KDE4 worked surprisingly fast .

 To understand whether difference is among FreeBSD or DruidBSD , I have
 installed
 FreeBSD 9.0 Release amd64 and KDE4 on the same computer instead of DruidBSD
 .

 The KDE4 has worked flawlesly i.e. , means very fast .

 To make equivalent the installations on both computers , I have installed
 FreeBSD 9.0 Release amd64 and KDE4 on the slow computer exactly as in fast
 computer .


 Starting times after first boot ( to eliminate initialization effects ) are
 the following
 ( All timings are from root ) :


 From startx ( which contains exec ... kde4 ... )
 to   appearance of KDE menu symbol at the bottom left corner :


 Fast computer : 8 GB : 0+ (  1 ) minute ( 4 x 2 GB )
 Slow computer : 4 GB : 2+ (  3 ) minutes ( 2 x 2 GB ) ( 2 x ! GB chips
 removed ) ,
 6 GB : 8+ (  9 ) minutes ( 2 x ( 2 , 1 ) GB ) .
 ( Memory chip installation conforms to main board manual . )
 ( The clock does not have second counter . )

 Fast Computer
   CPU : Intel Pentium Dual CPU E2220 @ 2.40 GHz ( 2397.65-MHz K-8class CPU )
   ACPI APIC Table :  INTEL DG965WH 

 Slow Computer
   CPU : Intel Core 2 QUAD CPU Q6600 @ 2.40 GHz ( 2397.65-MHz K-8class CPU )
   ACPI APIC Table :  INTEL DG965WH 

 ( The main boards are the same ) .
 ( All of the memory chips are the same : Kingston HyperX 800 MHz )



 I could not understand the reason(s) of the differences .


 Boot DMESG outputs are attached .


Compare 'sysctl kern.timecounter'.
That's the only difference I could see. Also, I'd try to disable two
cores in the bios of the quad-core machine and see if it changes
anything. Just to rule out scheduler issues.

Have you tried memtest86 to see if RAM throughput and CPU-cache rates
are comparable?

-Harry




signature.asc
Description: OpenPGP digital signature

Re: beta2 panic: VAPPEND without VWRITE

2011-10-05 Thread Harald Schmalzbauer

schrieb Rick Macklem am 02.10.2011 00:39 (localtime):
 Harald Schmalzbauer wrote:
 schrieb Attilio Rao am 01.10.2011 16:49 (localtime):
 Can you please show the panic message?

 Sorry, I forgot to add it here:

 free indoe /var/123088 had 8 blocks
 panic: VAPPEND withour VWRITE
 cpuid = 0
 KDB: enter: panic
 [ thread pid 1445 tid 100126 ]
 Stopped at kbd_enter+0x2b: movq $0,0x918a52(%rip)
 db bt
 Tracing pid 1445 tid 100126 td 0xfe000510d460
 kdb_enter() at kbd_enter+0x3b
 panic() at panic+0x180
 vn_isdisk() at vn_isdisk
 ufs_accessx() at ufs_accessx+0x188
 vop_stdaccess() at vop_stdaccess+0x43
 unionfs_access() at unionfs_access+0x1c4
 vn_open_cred() at vn_open_cred+0x547
 kern_opneat() at kern_openat+0x1f9
 syscallenter() at syscallenter+0x1aa
 syscall() at syscall+0x4c
 Xfast_syscall() at Xfast_syscall+0xdd
 --- syscall (5, FreeBSD ELF64, open), rip = 0x801799f2c, rsp =
 0x7fffb388, rbp = 0x8 ---

 I'ts reproducable with exact the same hex-numbers with 'scp' when scp
 tries to alter knwon_hosts, which is on unionfs.

 You could try the attached one line patch. Since VAPPEND is a modifier
 for VWRITE, it makes sense to clear it along with VWRITE, I think?
 
 rick

Thanks for your help. Unfortunately I can neither comment on the patch,
nor reproduce the panic... I tried the patch and all seems fine, but
also without the patch (the exactly same kernel some days ago, but
machine was rebooted since). Of course, the machine has been rebooted
after the panic too, when I was able to reproduce the panic easily.
Any idea why the pnaic was once reproducable and now isn't anymore? Of
course, _nothing_ was changed since then, besides bootme flag on one
GPT partition. 9-beta2 never booted since then... No hardware has
changed either !?! *kopfkratz*

Thanks,

-Harry

 Here's some LORs, I havenÄt checked if they're already known. I don't
 have the known-LORs-URL handy...

 lock order reversal:
 1st 0xfe000519c278 unionfs (unionfs) @
 /usr/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:356
 2nd 0xfe000519c458 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2246
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 kdb_backtrace() at kdb_backtrace+0x37
 _witness_debugger() at _witness_debugger+0x2e
 witness_checkorder() at witness_checkorder+0x807
 __lockmgr_args() at __lockmgr_args+0xdc6
 ffs_lock() at ffs_lock+0x8c
 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
 _vn_lock() at _vn_lock+0x47
 vputx() at vputx+0x328
 unionfs_noderem() at unionfs_noderem+0x1c4
 unionfs_reclaim() at unionfs_reclaim+0x11
 vgonel() at vgonel+0x105
 vrecycle() at vrecycle+0x4c
 unionfs_inactive() at unionfs_inactive+0x20
 vinactive() at vinactive+0x72
 vputx() at vputx+0x386
 kern_statat_vnhook() at kern_statat_vnhook+0x11d
 kern_statat() at kern_statat+0x15
 stat() at stat+0x2a
 syscallenter() at syscallenter+0x1aa
 syscall() at syscall+0x4c
 Xfast_syscall() at Xfast_syscall+0xdd
 --- syscall (188, FreeBSD ELF64, stat), rip = 0x800dc7ecc, rsp =
 0x7fffd6a8, rbp = 0x801441190 ---
 lock order reversal:
 1st 0xff80e9bf59f8 bufwait (bufwait) @
 /usr/src/sys/kern/vfs_bio.c:2658
 2nd 0xfe00051a7a00 dirhash (dirhash) @
 /usr/src/sys/ufs/ufs/ufs_dirhash.c:284
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 kdb_backtrace() at kdb_backtrace+0x37
 _witness_debugger() at _witness_debugger+0x2e
 witness_checkorder() at witness_checkorder+0x807
 _sx_xlock() at _sx_xlock+0x55
 ufsdirhash_acquire() at ufsdirhash_acquire+0x33
 ufsdirhash_add() at ufsdirhash_add+0x19
 ufs_direnter() at ufs_direnter+0x909
 ufs_mkdir() at ufs_mkdir+0x44d
 VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93
 kern_mkdirat() at kern_mkdirat+0x290
 syscallenter() at syscallenter+0x1aa
 syscall() at syscall+0x4c
 Xfast_syscall() at Xfast_syscall+0xdd
 --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800933eec, rsp =
 0x7fffd768, rbp = 0x800c07050 ---
 lock order reversal:
 1st 0xfe000514f818 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134
 2nd 0xff80e9bf59f8 bufwait (bufwait) @
 /usr/src/sys/ufs/ffs/ffs_vnops.c:260
 3rd 0xfe0005706278 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134
 KDB: stack backtrace:
 db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
 kdb_backtrace() at kdb_backtrace+0x37
 _witness_debugger() at _witness_debugger+0x2e
 witness_checkorder() at witness_checkorder+0x807
 __lockmgr_args() at __lockmgr_args+0xdc6
 ffs_lock() at ffs_lock+0x8c
 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
 _vn_lock() at _vn_lock+0x47
 vget() at vget+0x7b
 vfs_hash_get() at vfs_hash_get+0xd5
 ffs_vgetf() at ffs_vgetf+0x48
 softdep_sync_buf() at softdep_sync_buf+0x393
 ffs_syncvnode() at ffs_syncvnode+0x2b3
 ffs_truncate() at ffs_truncate+0x477
 ufs_direnter() at ufs_direnter+0x73b
 ufs_mkdir() at ufs_mkdir+0x44d
 VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93
 kern_mkdirat() at kern_mkdirat+0x290
 syscallenter() at syscallenter+0x1aa
 syscall() at syscall+0x4c
 Xfast_syscall() at Xfast_syscall+0xdd
 --- syscall (136, FreeBSD

beta2 panic: VAPPEND without VWRITE

2011-10-01 Thread Harald Schmalzbauer

Hello,

I got the following panic with 9.0-beta2:

cpuid = 0
KDB: enter: panic
[ thread pid 1445 tid 100126 ]
Stopped at  kbd_enter+0x2b: movq$0,0x918a52(%rip)
db bt
Tracing pid 1445 tid 100126 td 0xfe000510d460
kdb_enter() at kbd_enter+0x3b
panic() at panic+0x180
vn_isdisk() at vn_isdisk
ufs_accessx() at ufs_accessx+0x188
vop_stdaccess() at vop_stdaccess+0x43
unionfs_access() at unionfs_access+0x1c4
vn_open_cred() at vn_open_cred+0x547
kern_opneat() at kern_openat+0x1f9
syscallenter() at syscallenter+0x1aa
syscall() at syscall+0x4c
Xfast_syscall() at Xfast_syscall+0xdd
--- syscall (5, FreeBSD ELF64, open), rip = 0x801799f2c, rsp =
0x7fffb388, rbp = 0x8 ---

Please tell how to provide more information if needed.

Thanks,

-Harry



signature.asc
Description: OpenPGP digital signature

Re: beta2 panic: VAPPEND without VWRITE

2011-10-01 Thread Harald Schmalzbauer

schrieb Attilio Rao am 01.10.2011 16:49 (localtime):
 Can you please show the panic message?

Sorry, I forgot to add it here:

free indoe /var/123088 had 8 blocks
panic: VAPPEND withour VWRITE
 cpuid = 0
 KDB: enter: panic
 [ thread pid 1445 tid 100126 ]
 Stopped at  kbd_enter+0x2b: movq$0,0x918a52(%rip)
 db bt
 Tracing pid 1445 tid 100126 td 0xfe000510d460
 kdb_enter() at kbd_enter+0x3b
 panic() at panic+0x180
 vn_isdisk() at vn_isdisk
 ufs_accessx() at ufs_accessx+0x188
 vop_stdaccess() at vop_stdaccess+0x43
 unionfs_access() at unionfs_access+0x1c4
 vn_open_cred() at vn_open_cred+0x547
 kern_opneat() at kern_openat+0x1f9
 syscallenter() at syscallenter+0x1aa
 syscall() at syscall+0x4c
 Xfast_syscall() at Xfast_syscall+0xdd
 --- syscall (5, FreeBSD ELF64, open), rip = 0x801799f2c, rsp =
 0x7fffb388, rbp = 0x8 ---

I'ts reproducable with exact the same hex-numbers with 'scp' when scp
tries to alter knwon_hosts, which is on unionfs.

Here's some LORs, I havenÄt checked if they're already known. I don't
have the known-LORs-URL handy...

lock order reversal:
 1st 0xfe000519c278 unionfs (unionfs) @
/usr/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:356
 2nd 0xfe000519c458 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2246
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x807
__lockmgr_args() at __lockmgr_args+0xdc6
ffs_lock() at ffs_lock+0x8c
VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
_vn_lock() at _vn_lock+0x47
vputx() at vputx+0x328
unionfs_noderem() at unionfs_noderem+0x1c4
unionfs_reclaim() at unionfs_reclaim+0x11
vgonel() at vgonel+0x105
vrecycle() at vrecycle+0x4c
unionfs_inactive() at unionfs_inactive+0x20
vinactive() at vinactive+0x72
vputx() at vputx+0x386
kern_statat_vnhook() at kern_statat_vnhook+0x11d
kern_statat() at kern_statat+0x15
stat() at stat+0x2a
syscallenter() at syscallenter+0x1aa
syscall() at syscall+0x4c
Xfast_syscall() at Xfast_syscall+0xdd
--- syscall (188, FreeBSD ELF64, stat), rip = 0x800dc7ecc, rsp =
0x7fffd6a8, rbp = 0x801441190 ---
lock order reversal:
 1st 0xff80e9bf59f8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658
 2nd 0xfe00051a7a00 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c:284
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x807
_sx_xlock() at _sx_xlock+0x55
ufsdirhash_acquire() at ufsdirhash_acquire+0x33
ufsdirhash_add() at ufsdirhash_add+0x19
ufs_direnter() at ufs_direnter+0x909
ufs_mkdir() at ufs_mkdir+0x44d
VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93
kern_mkdirat() at kern_mkdirat+0x290
syscallenter() at syscallenter+0x1aa
syscall() at syscall+0x4c
Xfast_syscall() at Xfast_syscall+0xdd
--- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800933eec, rsp =
0x7fffd768, rbp = 0x800c07050 ---
lock order reversal:
 1st 0xfe000514f818 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134
 2nd 0xff80e9bf59f8 bufwait (bufwait) @
/usr/src/sys/ufs/ffs/ffs_vnops.c:260
 3rd 0xfe0005706278 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2134
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
kdb_backtrace() at kdb_backtrace+0x37
_witness_debugger() at _witness_debugger+0x2e
witness_checkorder() at witness_checkorder+0x807
__lockmgr_args() at __lockmgr_args+0xdc6
ffs_lock() at ffs_lock+0x8c
VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b
_vn_lock() at _vn_lock+0x47
vget() at vget+0x7b
vfs_hash_get() at vfs_hash_get+0xd5
ffs_vgetf() at ffs_vgetf+0x48
softdep_sync_buf() at softdep_sync_buf+0x393
ffs_syncvnode() at ffs_syncvnode+0x2b3
ffs_truncate() at ffs_truncate+0x477
ufs_direnter() at ufs_direnter+0x73b
ufs_mkdir() at ufs_mkdir+0x44d
VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93
kern_mkdirat() at kern_mkdirat+0x290
syscallenter() at syscallenter+0x1aa
syscall() at syscall+0x4c
Xfast_syscall() at Xfast_syscall+0xdd
--- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800933eec, rsp =
0x7fffdbb8, rbp = 0x7fffdee6 ---

Thanks,

-Harry

 cpuid = 0
 KDB: enter: panic
 [ thread pid 1445 tid 100126 ]
 Stopped at  kbd_enter+0x2b: movq$0,0x918a52(%rip)
 db bt
 Tracing pid 1445 tid 100126 td 0xfe000510d460
 kdb_enter() at kbd_enter+0x3b
 panic() at panic+0x180
 vn_isdisk() at vn_isdisk
 ufs_accessx() at ufs_accessx+0x188
 vop_stdaccess() at vop_stdaccess+0x43
 unionfs_access() at unionfs_access+0x1c4
 vn_open_cred() at vn_open_cred+0x547
 kern_opneat() at kern_openat+0x1f9
 syscallenter() at syscallenter+0x1aa
 syscall() at syscall+0x4c
 Xfast_syscall() at Xfast_syscall+0xdd
 --- syscall (5, FreeBSD ELF64, open), rip = 0x801799f2c, rsp =
 0x7fffb388, rbp = 0x8 ---



signature.asc
Description: OpenPGP digital signature

OT [was: Re: HEADS UP: /bin and /sbin are now dynamically linked]

2003-11-28 Thread Harald Schmalzbauer

On Friday 28 November 2003 21:03, Tim Kientzle wrote:
 David O'Brien wrote:
  On Wed, Nov 26, 2003 at 10:37:48AM -0800, Tim Kientzle wrote:
 and [/usr/bin/ftp] doesn't support HTTP.
 
$ /usr/bin/ftp http://www.theregister.co.uk/content/6/32524.html
Requesting http://www.theregister.co.uk/content/6/32524.html
100% |*| 22559  35.32 KB/s
  00:00 ETA 22559 bytes retrieved in 00:00 (35.28 KB/s)

 Wow!  Learn something new every day around here.

Well that's bizarre IMHO. I never had guessed a tool called ftp would 
unterstand http!

Just my 2¢

-Harry


 Tim


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


pgp0.pgp
Description: signature

Re: Nvidia problem fixed in current?

2003-11-26 Thread Harald Schmalzbauer

On Wednesday 26 November 2003 18:40, Justin Smith wrote:
 1. Was the problem with the nvidia driver ever fixed? (I reported this
 more than a month ago --- the kernel nvidia driver only works with
 parameters set to lower the speed of the interface, and even then failed
 with some OpenGL programs like OpenUniverse).

If you're talking about the nvidia driver (not the xfree86) then this isn't 
true in general. It's been working here without any tweaks fine since 
-current short after 5.1-release, also OpenUniverse is running without 
problems here.
But the nvidia driver is still the same, you have to talk to nvidia to release 
a new one.


 2. Can one upgrade to 5.2 beta by cvsupping to current and rebuilding
 world and kernel?

Yes.


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


pgp0.pgp
Description: signature

Re: please test pcm patch

2003-11-26 Thread Harald Schmalzbauer

On Wednesday 26 November 2003 19:54, Mathew Kanner wrote:
 Hello All,
   Please test a pcm patch that releases the channel lock around
 calls to uio move.  This is a more complete patch than the previous
 one as it also does the _read routine.  I will ask the RE to commit
 this if I hear a couple of it works.

it works

But I haven't had any problems before (besides some replay delay, thus asynch 
audio/video)

Here is what dmesg prints:
pcm0: Intel ICH2 (82801BA) port 0xef00-0xef3f,0xe800-0xe8ff irq 17 at device 
31.5 on pci0
pcm0: Analog Devices AD1885 AC97 Codec
pcm0: measured ac97 link rate at 55934 Hz

Thanks,

-Harry


 Pointed out by:   Artur Poplawski
 Explained by: Don Lewis

   --Mat


pgp0.pgp
Description: signature

Re: i have linux mandrake

2003-11-24 Thread Harald Schmalzbauer

On Sunday 23 November 2003 23:32, james wrote:
 I am trying to migrate to free bsd is there a way for me to put freebsd
 on with it woth out loosing mandrake or the files in it ?

This depends on your current disk layout. In general: Yes. You need one spare 
partition (called slice in FreeBSD) which you can assign hard drive space and 
create labels inside (also sometimes called Partition)

The handbook is always a good point to start, in your case:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install.html

-Harry


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




pgp0.pgp
Description: signature

Re: Updated acpi_cpu patch

2003-11-19 Thread Harald Schmalzbauer

On Wednesday 19 November 2003 16:31, Nate Lawson wrote:
 Ok, here's the final patch.  I believe it fixes both problems.

*SCHNIP*

Yep, seems really final. I downloaded the acpi_cpi.c from cvs-web to be sure 
to have the correct one and applied your patch.

hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: 0
hw.acpi.cpu.cx_history: 27743/0

No Problems at booting/rebooting

Attached my dmesg but it doesn't show anything unusual/debug.

Thanks,

-Harry
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 #50: Wed Nov 19 21:01:37 CET 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE
Preloaded elf kernel /boot/kernel/kernel at 0xc09d9000.
Preloaded elf module /boot/kernel/linux.ko at 0xc09d9244.
Preloaded elf module /boot/kernel/nvidia.ko at 0xc09d92f0.
ACPI APIC Table: D815EA EA81510A
Timecounter i8254 frequency 1183576 Hz quality 0
CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.82-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x6b1  Stepping = 1
  
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 268173312 (255 MB)
avail memory = 250781696 (239 MB)
ioapic0: Changing APIC ID to 1
ioapic0 Version 2.0 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc07760c2 (122)
VESA: NVIDIA
acpi0: D815EA D815EPFV on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 12 entries at 0xc00f2a10
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0: CPU port 0x530-0x537 on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci2: PCI bus on pcib1
pcib1: slot 0 INTA is routed to irq 16
nvidia0: GeForce4 MX 440 with AGP8X mem 0xf000-0xf3ff,0xfd00-0xfdff 
irq 16 at device 0.0 on pci2
pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0
pci1: ACPI PCI bus on pcib2
fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xdf00-0xdf3f mem 
0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1
fxp0: Ethernet address 00:03:47:f0:c2:ef
miibus0: MII bus on fxp0
inphy0: i82562ET 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH2 UDMA100 controller port 0xffa0-0xffaf at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xef40-0xef5f irq 19 at 
device 31.2 on pci0
usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ichsmb0: Intel 82801BA (ICH2) SMBus controller port 0xefa0-0xefaf irq 17 at device 
31.3 on pci0
smbus0: System Management Bus on ichsmb0
smb0: SMBus generic I/O on smbus0
uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xef80-0xef9f irq 23 at 
device 31.4 on pci0
usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub2: Standard Microsystems product 0x0140, class 9/0, rev 1.10/0.00, addr 2
uhub2: 4 ports with 4 removable, self powered
ums0: Microsoft Microsoft IntelliMouse® Explorer, rev 1.10/1.14, addr 3, iclass 3/1
ums0: 5 buttons and Z dir.
uhub3: Texas Instruments General Purpose USB Hub, class 9/0, rev 1.10/1.01, addr 4
uhub3: 2 ports with 2 removable, bus powered
pcm0: Intel ICH2 (82801BA) port 0xef00-0xef3f,0xe800-0xe8ff irq 17 at device 31.5 on 
pci0
pcm0: Analog Devices AD1885 AC97 Codec
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 
0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
orm0: Option ROMs at iomem 0xd0800-0xd17ff,0xcf800-0xd07ff on isa0
pmtimer0 on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 12 virtual consoles, flags=0x300
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
Timecounter TSC frequency 1095817986 Hz quality 800
Timecounters tick every 1.000 msec
GEOM: create disk ad0 dp=0xc2dbbd60
ad0: 39083MB Maxtor 4D040H2 [79408/16/63] at ata0-master UDMA100
acd0: CDROM SONY CDU4811 at ata1-master

Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)

2003-11-18 Thread Harald Schmalzbauer

On Tuesday 18 November 2003 18:58, you wrote:
 On Tue, 18 Nov 2003, Harald Schmalzbauer wrote:
  On Tuesday 18 November 2003 03:37, you wrote:
   Sorry I wasn't more clear.  I need you to print the contents like this:
 print *cpu_cx_count
 
  cpu_cx_count 1
  cpu_cx_lowest 0
  cpu_idle_hook c0468300
  cpu_cx_next 0
 
  I hope these are the correct values.

 Thanks, those are the correct values for your box.  I just posted a patch
 that should address the boot-time panic.  Please revert old patches and
 try it.

Yep, this looks good. Perhaps you're interested in the following line which 
arose for the first time during boot:

C0? cx_next 0 cx_count 1

And here is what you requested in your first patch:

cale:~ sysctl hw.acpi.cpu
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.cpu.cx_lowest: 0
hw.acpi.cpu.cx_history: 0/0

How do I know when this will be comitted to .

Thanks a lot,

-Harry


 -Nate


pgp0.pgp
Description: signature

Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)

2003-11-18 Thread Harald Schmalzbauer

On Wednesday 19 November 2003 02:09, Eric Anderson wrote:
 Harald Schmalzbauer wrote:
 On Tuesday 18 November 2003 18:58, you wrote:
 On Tue, 18 Nov 2003, Harald Schmalzbauer wrote:
 On Tuesday 18 November 2003 03:37, you wrote:
 Sorry I wasn't more clear.  I need you to print the contents like this:
   print *cpu_cx_count
 
 cpu_cx_count 1
 cpu_cx_lowest 0
 cpu_idle_hook c0468300
 cpu_cx_next 0
 
 I hope these are the correct values.
 
 Thanks, those are the correct values for your box.  I just posted a patch
 that should address the boot-time panic.  Please revert old patches and
 try it.
 
 Yep, this looks good. Perhaps you're interested in the following line
  which arose for the first time during boot:
 
 C0? cx_next 0 cx_count 1
 
 And here is what you requested in your first patch:
 
 cale:~ sysctl hw.acpi.cpu
 hw.acpi.cpu.cx_supported: C1/0
 hw.acpi.cpu.cx_lowest: 0
 hw.acpi.cpu.cx_history: 0/0

 Ok - what do I need to do to try this new acpi stuff out?  I'm running
 -current as of Nov 14th, and I'd like to help debug/test this on my
 notebook..

Try the patch Nate posted in Updated acpi_cpu patch. For convinience I 
attached it. That's all I can tell you.

-Harry


 Eric
Index: sys/dev/acpica/acpi_cpu.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
retrieving revision 1.19
diff -u -r1.19 acpi_cpu.c
--- sys/dev/acpica/acpi_cpu.c	15 Nov 2003 19:26:05 -	1.19
+++ sys/dev/acpica/acpi_cpu.c	18 Nov 2003 17:46:23 -
@@ -1,5 +1,5 @@
 /*-
- * Copyright (c) 2003 Nate Lawson
+ * Copyright (c) 2003 Nate Lawson (SDG)
  * Copyright (c) 2001 Michael Smith
  * All rights reserved.
  *
@@ -77,9 +77,11 @@
 device_t		 cpu_dev;
 ACPI_HANDLE		 cpu_handle;
 uint32_t		 cpu_id;	/* ACPI processor id */
+uint32_t		 cpu_p_blk;	/* ACPI P_BLK location */
+uint32_t		 cpu_p_blk_len;	/* P_BLK length (must be 6). */
 struct resource	*cpu_p_cnt;	/* Throttling control register */
 struct acpi_cx	 cpu_cx_states[MAX_CX_STATES];
-int			 cpu_bm_ok;	/* Bus mastering control available. */
+int			 cpu_cx_count;	/* Number of valid Cx states. */
 };

 #define CPU_GET_REG(reg, width) 	\
@@ -116,10 +118,9 @@
 #define PCI_REVISION_4M		3

 /* Platform hardware resource information. */
-static uint32_t		 cpu_p_blk;	/* ACPI P_BLK location */
-static uint32_t		 cpu_p_blk_len;	/* P_BLK length (must be 6). */
 static uint32_t		 cpu_smi_cmd;	/* Value to write to SMI_CMD. */
 static uint8_t		 cpu_pstate_cnt;/* Register to take over throttling. */
+static uint8_t		 cpu_cst_cnt;	/* Indicate we are _CST aware. */
 static uint32_t		 cpu_rid;	/* Driver-wide resource id. */
 static uint32_t		 cpu_quirks;	/* Indicate any hardware bugs. */

@@ -146,11 +147,13 @@

 static int	acpi_cpu_probe(device_t dev);
 static int	acpi_cpu_attach(device_t dev);
+static int	acpi_cpu_detach(device_t dev);
 static int	acpi_cpu_throttle_probe(struct acpi_cpu_softc *sc);
 static int	acpi_cpu_cx_probe(struct acpi_cpu_softc *sc);
 static int	acpi_cpu_cx_cst(struct acpi_cpu_softc *sc);
 static void	acpi_cpu_startup(void *arg);
 static void	acpi_cpu_startup_throttling(void);
+static void	acpi_cpu_startup_cx(void);
 static void	acpi_cpu_throttle_set(uint32_t speed);
 static void	acpi_cpu_idle(void);
 static void	acpi_cpu_c1(void);
@@ -166,6 +169,7 @@
 /* Device interface */
 DEVMETHOD(device_probe,	acpi_cpu_probe),
 DEVMETHOD(device_attach,	acpi_cpu_attach),
+DEVMETHOD(device_detach,	acpi_cpu_detach),

 {0, 0}
 };
@@ -178,6 +182,7 @@

 static devclass_t acpi_cpu_devclass;
 DRIVER_MODULE(acpi_cpu, acpi, acpi_cpu_driver, acpi_cpu_devclass, 0, 0);
+
 static int
 acpi_cpu_probe(device_t dev)
 {
@@ -272,11 +277,10 @@
 AcpiEvaluateObject(sc-cpu_handle, _INI, NULL, NULL);

 /* Get various global values from the Processor object. */
-cpu_p_blk = pobj.Processor.PblkAddress;
-cpu_p_blk_len = pobj.Processor.PblkLength;
+sc-cpu_p_blk = pobj.Processor.PblkAddress;
+sc-cpu_p_blk_len = pobj.Processor.PblkLength;
 ACPI_DEBUG_PRINT((ACPI_DB_IO, acpi_cpu%d: P_BLK at %#x/%d%s\n,
-		 device_get_unit(dev), cpu_p_blk, cpu_p_blk_len,
-		 sc-cpu_p_cnt ?  :  (shadowed)));
+		 device_get_unit(dev), sc-cpu_p_blk, sc-cpu_p_blk_len));

 acpi_sc = acpi_device_get_parent_softc(dev);
 sysctl_ctx_init(acpi_cpu_sysctl_ctx);
@@ -297,7 +301,8 @@
 if (thr_ret == 0 || cx_ret == 0) {
 	status = AcpiInstallNotifyHandler(sc-cpu_handle, ACPI_DEVICE_NOTIFY,
 	  acpi_cpu_notify, sc);
-	AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, sc);
+	if (device_get_unit(dev) == 0)
+	AcpiOsQueueForExecution(OSD_PRIORITY_LO, acpi_cpu_startup, NULL);
 } else {
 	sysctl_ctx_free(acpi_cpu_sysctl_ctx);
 }
@@ -306,6 +311,21 @@
 }

 static int
+acpi_cpu_detach(device_t dev)
+{
+
+/* Disable any entry to the idle function. */
+cpu_cx_count = 0;
+
+#ifdef SMP
+/* Wait for all processors to exit acpi_cpu_idle

Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)

2003-11-17 Thread Harald Schmalzbauer

On Monday 17 November 2003 18:45, Nate Lawson wrote:
 On Mon, 17 Nov 2003, Harald Schmalzbauer wrote:
  On Sunday 16 November 2003 21:11, Nate Lawson wrote:
   The panic you see is a result of the new acpi_cpu driver, not ULE.  In
   any case, it appears that acpi_cpu_idle is being called and trying to
   read one of the processor control registers before they are present. 
   Please send me privately the output of:
  acpidump -t -d  harald-MachineType.asl
  
   As a workaround, please set this in loader.conf:
  debug.acpi.disable=cpu
  
   That will allow you to get running and give me some time to look into
   this.
 
  Now I followed your advise and found out the following (source from some
  hours ago, 4BSD scheduler, and the acpidump went away to you by private
  mail) The panic only occurs if the nvidia.ko module is was loaded.
  I use it straight from the ports.
  But your sysctl tweak keeps the whole thing working (I'm writing with
  kmail)!

 Please try the patch below.  It does more than fix your problem but the
 other changes will be needed eventually anyways.  If your system boots ok,
 please send me the output of sysctl hw.acpi.cpu

 Also, be sure to comment out the disable CPU line in loader.conf while
 testing the patch.

Sorry, things got worse. Now it panics even if the nvidia module is not 
loaded.
But the debug.acpi.disable=cpu tweak is still working. I'm using the kernel 
with your patch(es) at the moment.

cale:/home/harry# sysctl hw.acpi.cpu
sysctl: unknown oid 'hw.acpi.cpu'

Thanks a lot,

-Harry


 Thanks,
 Nate


 Index: sys/dev/acpica/acpi_cpu.c
 ===
 RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
 retrieving revision 1.19
 diff -u -r1.19 acpi_cpu.c
 --- sys/dev/acpica/acpi_cpu.c 15 Nov 2003 19:26:05 -  1.19
 +++ sys/dev/acpica/acpi_cpu.c 17 Nov 2003 17:39:54 -
 @@ -78,8 +78,8 @@
  ACPI_HANDLE   cpu_handle;
  uint32_t  cpu_id;/* ACPI processor id */
  struct resource  *cpu_p_cnt; /* Throttling control register */
 +int   cpu_cx_count;  /* Number of valid Cx states. */
  struct acpi_cxcpu_cx_states[MAX_CX_STATES];
 -int   cpu_bm_ok; /* Bus mastering control available. */
  };

  #define CPU_GET_REG(reg, width)  \
 @@ -151,6 +151,7 @@
  static int   acpi_cpu_cx_cst(struct acpi_cpu_softc *sc);
  static void  acpi_cpu_startup(void *arg);
  static void  acpi_cpu_startup_throttling(void);
 +static void  acpi_cpu_startup_cx(void);
  static void  acpi_cpu_throttle_set(uint32_t speed);
  static void  acpi_cpu_idle(void);
  static void  acpi_cpu_c1(void);
 @@ -406,8 +407,7 @@
  {
  ACPI_GENERIC_ADDRESS gas;
  struct acpi_cx   *cx_ptr;
 -struct sbuf   sb;
 -int   i, error;
 +int   error;

  /* Bus mastering arbitration control is needed for C3. */
  if (AcpiGbl_FADT-V1_Pm2CntBlk == 0 || AcpiGbl_FADT-Pm2CntLen == 0) {
 @@ -420,11 +420,9 @@
   * First, check for the ACPI 2.0 _CST sleep states object.
   * If not usable, fall back to the P_BLK's P_LVL2 and P_LVL3.
   */
 -cpu_cx_count = 0;
 +sc-cpu_cx_count = 0;
  error = acpi_cpu_cx_cst(sc);
  if (error != 0) {
 - if (cpu_p_blk_len != 6)
 - return (ENXIO);
   cx_ptr = sc-cpu_cx_states;

   /* C1 has been required since just after ACPI 1.0 */
 @@ -432,7 +430,10 @@
   cx_ptr-trans_lat = 0;
   cpu_non_c3 = 0;
   cx_ptr++;
 - cpu_cx_count++;
 + sc-cpu_cx_count++;
 +
 + if (cpu_p_blk_len != 6)
 + goto done;

   /* Validate and allocate resources for C2 (P_LVL2). */
   gas.AddressSpaceId = ACPI_ADR_SPACE_SYSTEM_IO;
 @@ -446,7 +447,7 @@
   cx_ptr-trans_lat = AcpiGbl_FADT-Plvl2Lat;
   cpu_non_c3 = 1;
   cx_ptr++;
 - cpu_cx_count++;
 + sc-cpu_cx_count++;
   }
   }

 @@ -461,40 +462,16 @@
   cx_ptr-type = ACPI_STATE_C3;
   cx_ptr-trans_lat = AcpiGbl_FADT-Plvl3Lat;
   cx_ptr++;
 - cpu_cx_count++;
 + sc-cpu_cx_count++;
   }
   }
  }

 +done:
  /* If no valid registers were found, don't attach. */
 -if (cpu_cx_count == 0)
 +if (sc-cpu_cx_count == 0)
   return (ENXIO);

 -sbuf_new(sb, cpu_cx_supported, sizeof(cpu_cx_supported),
 SBUF_FIXEDLEN); -for (i = 0; i  cpu_cx_count; i++) {
 - sbuf_printf(sb, C%d/%d , sc-cpu_cx_states[i].type,
 - sc-cpu_cx_states[i].trans_lat);
 -}
 -sbuf_trim(sb);
 -sbuf_finish(sb);
 -SYSCTL_ADD_STRING(acpi_cpu_sysctl_ctx,
 -   SYSCTL_CHILDREN(acpi_cpu_sysctl_tree),
 -   OID_AUTO, cx_supported, CTLFLAG_RD, cpu_cx_supported,
 -   0, Cx/microsecond values for supported Cx states

Re: kernel panic with todays source

On Sunday 16 November 2003 05:32, Harald Schmalzbauer wrote:
 Hi,

 I saw that something has changed on ULE and wanted to give it a try but
 with sources from ~ So 16 Nov 2003 04:00 UTC I get the following kernel
 panic just before disk/geom and after Timecounter TSC frequency
 1095341787 Hz quality 800:

 Fatal trap 12 :page fault while in kernel mode
 fault virtual address =0x24
 fault code=supervisor read, page not present
 instruction pointer   =0x8:0xc056c706
 stack pointer =0x10:0xcdca4ca4
 frame pointer =0x10:0xcdca4ca4
 code segment  =base 0x0, limit 0xf, type 0x1b
   =DPL 0, pres 1, def32 1, gran 1
 processor eflags  =resume, IOPL=0
 current process   =11 (idle)
 trap number   =12
 panic: page fault

I recvsuped some hours ago and now I have the following (this time with DDB 
trace):

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x24
fault code  = supervisor read, page not present
instruction  pointer= 0x8:0xc0571d36
stack pointer   = 0x10:0xcdca4ca4
frame pointer   = 0x10:0xcdca4ca4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL=0
current process = 11 (idle)
kernel: type 12 trap, code=0
Stopped at  rman_get_bustag+0x6:movl0x24(%eax),%eax
db trace
rman_get_bustag(0,cdca4cbc,c2d2f3d0,4ab1c,3a7ee2) at rman_get_bustag+0x6
acpi_cpu_idle(cdca4d08,c0535345,ffef,42b30,42830) at acpi_cpu_idle+0x1c3
cpu_idle(ffef,42b30,42830,42b30,43724) at cpu_idle+0x1f
idle_proc(0,cdca4d48,43160,437a4,3) at idle_proc+0x25
fork_exit(0c0535320,0,cdca4d48) at fork_exit+0x80
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xcdca4d7c, ebp = 0 ---

This GDB was configured as i386-undermydesk-freebsd...
(kgdb) l *0xc0571d36
0xc0571d36 is in rman_get_bustag (/usr/src/sys/kern/subr_rman.c:661).
656 }
657
658 bus_space_tag_t
659 rman_get_bustag(struct resource *r)
660 {
661 return (r-r_bustag);
662 }
663
664 void
665 rman_set_bushandle(struct resource *r, bus_space_handle_t h)
(kgdb) l *0xcdca4ca4
No source file for address 0xcdca4ca4.

Hope this helps.

-Harry


pgp0.pgp
Description: signature

Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)

On Sunday 16 November 2003 21:11, Nate Lawson wrote:
 The panic you see is a result of the new acpi_cpu driver, not ULE.  In any
 case, it appears that acpi_cpu_idle is being called and trying to read one
 of the processor control registers before they are present.  Please send
 me privately the output of:
acpidump -t -d  harald-MachineType.asl

 As a workaround, please set this in loader.conf:
debug.acpi.disable=cpu

 That will allow you to get running and give me some time to look into
 this.

Now I followed your advise and found out the following (source from some hours 
ago, 4BSD scheduler, and the acpidump went away to you by private mail)
The panic only occurs if the nvidia.ko module is was loaded.
I use it straight from the ports.
But your sysctl tweak keeps the whole thing working (I'm writing with kmail)!

Hope this helps (anyway, this driver is absolutle mandatory for my 
workstation!)

Thanks,

-Harry


 Thanks,
 -Nate


pgp0.pgp
Description: signature

init and USB oddities-ULE-ATA

Salve,

since about one day kill 1 and init 1 don't work anymore!
Now I don't know how to change to single user mode from normal boot now. 
Usually I do installworld in singleuser mode.

Then I see the following lines on dmesg which I don't know how to hanlde:
1)
warning: KLD '/boot/kernel/linprocfs.ko' is newer than the linker.hints file
perhaps recompiling linux-base?
2)
module_register: module uhub/ums already exists!
Module uhub/ums failed to register: 17

Then I still have the problem that hw.ata.atapi_dma=1 seems to have no effect.
When I do atacontrol mode 1 I get:
cale:/home/harry# atacontrol mode 1
Master = PIO4
Slave  = BIOSPIO

But sysctl hw.ata.atapi_dma showes:
cale:/home/harry# sysctl hw.ata.atapi_dma
hw.ata.atapi_dma: 1

Setting UDMA33 with atacontrol is working. Although it's easy to add a 
rc.local which does that task it's not the intetion of sysctls I think.

Next I'd like to report is what I already mentioned in ULE and very bad 
responsiveness
I followed Jeff Roberson hint and ran setiathome with nice 20. But this didn't 
really change anything.
With ULE and setiathome in the backgroug it's almost impossible to wait until 
a simple make clean from ports is done. I waited at least a quater of an 
hour where SCHED_4BSD needs about 15 Seconds (aof course, also running seti 
in the backgorund)
Even if I don't have seti running I can _feel_ significantly difference 
between ULE and 4BSD. ULE feels more sluggish with daily work under kde314 
and if you wan't to replay two mpegs at the same time it's impossible with 
ULE (mplayer) where 4BSD has absolutely no problems (with our without seti, 
doesnt make big difference)

So long, thank you all,

-Harry


pgp0.pgp
Description: signature

Re: init and USB oddities-ULE-ATA

On Monday 17 November 2003 05:25, Steve Kargl wrote:
 On Mon, Nov 17, 2003 at 04:39:08AM +0100, Harald Schmalzbauer wrote:
 Content-Description: signed data

  Salve,
 
  since about one day kill 1 and init 1 don't work anymore!
  Now I don't know how to change to single user mode from normal boot now.

 shutdown -r now will reboot the system.  There are
 a number of ways to get to single user mode as the
 system is rebooting.

I know that, but I'd like to change to singleuser mode like before.


 Note: your method does not boot the new kernel and Kirk's
 recent statfs changes may cause all sorts of problems
 for you.

No, I had running a kernel with the new statfs changes without any problems.
It's smoething shortly changed after the statfs changes. I'm very sure!


  Usually I do installworld in singleuser mode.

 You should reboot.

No.


  Then I see the following lines on dmesg which I don't know how to hanlde:
  1)
  warning: KLD '/boot/kernel/linprocfs.ko' is newer than the linker.hints
  file perhaps recompiling linux-base?
  2)
  module_register: module uhub/ums already exists!
  Module uhub/ums failed to register: 17

 Do you see these messages if you reboot the system?

Yes, that's what I meant. Sorry if that wasn't clear.
These lines show up while booting


  Next I'd like to report is what I already mentioned in ULE and very bad
  responsiveness   I followed Jeff Roberson hint and ran setiathome with
  nice 20. But this didn't really change anything.

 ULE has been rock solid for mei since Jeff's last
 major update.  Of course, I run neither setiathome
 nor KDE.
Give setiathome a try! You'll be astonished. And I'm sure the difference I 
_feel_ isn't dependend on kde. If you don't like kde replace it with our 
favourite wm/desktop. But you won't be able to play two mid to high-quality 
mpegs at the same time on a 1GHz machine where 4BSD scheduler does very well!

I haven't claimed ULE to be unstable though. I just wanted to highlight some 
issues which will be a big problem if 5.2-releas will have ULE as default!

-Harry


pgp0.pgp
Description: signature

Re: init and USB oddities-ULE-ATA

On Monday 17 November 2003 06:08, Steve Kargl wrote:
 On Mon, Nov 17, 2003 at 05:41:04AM +0100, Harald Schmalzbauer wrote:
 Content-Description: signed data

  On Monday 17 November 2003 05:25, Steve Kargl wrote:
   On Mon, Nov 17, 2003 at 04:39:08AM +0100, Harald Schmalzbauer wrote:
   Content-Description: signed data
  
Next I'd like to report is what I already mentioned in ULE and very
bad responsiveness   I followed Jeff Roberson hint and ran
setiathome with nice 20. But this didn't really change anything.
  
   ULE has been rock solid for me since Jeff's last
   major update.  Of course, I run neither setiathome
   nor KDE.
 
  Give setiathome a try! You'll be astonished.

 No thanks.  It's a waste of CPU cycle.

Well, certainly you're rigth. But I have spare cycles and with 4BSD scheduler 
they were handled very well.


  And I'm sure the difference I _feel_ isn't dependend on kde. If you
  don't like kde replace it with our favourite wm/desktop.

 I prefer fvwm2.  ULE works fairly well.

  But you won't be able to play two mid to high-quality
  mpegs at the same time on a 1GHz machine where 4BSD scheduler does very
  well!

 I can assure you that the numerical simulations I run, along with
 the make worlds, and compilations of gcc's tree-ssa branch
 stress the system.  I re-install over 100 ports today and the
 load average was rarely below 5.  I was use linux-opera and
 knews and sylpheed and several other program and noticed
 nor degradation in responsiveness.  Does seti cause a problem
 if you are not running X (or KDE).

Yes. The difference is the same. Like I originally mentioned (on one single 
cons25) with seti in the background (doesn't matter if nice is 15 or 20) it's 
almost impossible to wait until a make clean of a port with little 
dependencies (like nvidia-driver) finishes.


  I haven't claimed ULE to be unstable though. I just wanted to highlight
  some issues which will be a big problem if 5.2-releas will have ULE as
  default!

 If ULE is destined to be the default scheduler in 5-stable, then
 we need to have more people test it.

I can copy that. That's the reason why I started to try ULE. The notes in the 
kernel didn't convince me really;) It was a thread in a newsgroup and after 
posting my problems Kris told me to post in -current.

Best regards,

-Harry


pgp0.pgp
Description: signature

Re: init and USB oddities-ULE-ATA

On Monday 17 November 2003 06:08, Steve Kargl wrote:
 On Mon, Nov 17, 2003 at 05:41:04AM +0100, Harald Schmalzbauer wrote:
*SNIP*
 I can assure you that the numerical simulations I run, along with
 the make worlds, and compilations of gcc's tree-ssa branch
 stress the system.  I re-install over 100 ports today and the
 load average was rarely below 5.  I was use linux-opera and
 knews and sylpheed and several other program and noticed
 nor degradation in responsiveness.  Does seti cause a problem
 if you are not running X (or KDE).

That reflects my opinion that this awful interactivity only occurs if 
ATA-disk-access is involved!

Sorry for this second replay. I'm in hurry while I don't know why [EMAIL PROTECTED]

-Harry


  I haven't claimed ULE to be unstable though. I just wanted to highlight
  some issues which will be a big problem if 5.2-releas will have ULE as
  default!

 If ULE is destined to be the default scheduler in 5-stable, then
 we need to have more people test it.


pgp0.pgp
Description: signature

Re: init and USB oddities-ULE-ATA

On Monday 17 November 2003 06:42, Kris Kennaway wrote:
 On Mon, Nov 17, 2003 at 05:41:04AM +0100, Harald Schmalzbauer wrote:
  Give setiathome a try! You'll be astonished. And I'm sure the difference
  I _feel_ isn't dependend on kde. If you don't like kde replace it with
  our favourite wm/desktop. But you won't be able to play two mid to
  high-quality mpegs at the same time on a 1GHz machine where 4BSD
  scheduler does very well!
 
  I haven't claimed ULE to be unstable though. I just wanted to highlight
  some issues which will be a big problem if 5.2-releas will have ULE as
  default!

 Sorry if you've already mentioned this, but what threading system are
 you using (i.e. libc_r, libthr, libkse)?

Hmm, libc_r I think. I haven't justified anything so I think this still is the 
default.
I'd be glad if I understood these threading libraries (well, that's because 
I'm no C programmer) but should I try libkse in conjunction with ULE?
If yes, how do I do that? I bet it's a line in make.conf

Thanks,

-Harry


 Kris


pgp0.pgp
Description: signature

kernel panic with todays source

Hi,

I saw that something has changed on ULE and wanted to give it a try but with 
sources from ~ So 16 Nov 2003 04:00 UTC I get the following kernel panic just 
before disk/geom and after Timecounter TSC frequency 1095341787 Hz quality 
800:

Fatal trap 12   :page fault while in kernel mode
fault virtual address   =0x24
fault code  =supervisor read, page not present
instruction pointer =0x8:0xc056c706
stack pointer   =0x10:0xcdca4ca4
frame pointer   =0x10:0xcdca4ca4
code segment=base 0x0, limit 0xf, type 0x1b
=DPL 0, pres 1, def32 1, gran 1
processor eflags=resume, IOPL=0
current process =11 (idle)
trap number =12
panic: page fault

I do have compiled the kernel with makeoptions debug but I don't have a serial 
terminal nor firewire.

Let me know if I can help.

Attached my kernel config

Thanks,

-Harry

## Kernel for ASUS CUSL2 ##


## Generic Config
#---
machine i386
cpu I686_CPU
options PQ_CACHESIZE=256# color for 512k/16k cache
ident   CALE
makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols
options SCHED_4BSD  #4BSD scheduler
#optionsSCHED_ULE
options PROCFS  #Process filesystem (requires PSEUDOFS)
options COMPAT_43   #Compatible with BSD 4.3 [KEEP THIS!]
options COMPAT_FREEBSD4
options KTRACE  #ktrace(1) support
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions
options CLK_USE_I8254_CALIBRATION
options CLK_USE_TSC_CALIBRATION
options HZ=2000
options PERFMON
#options MAC
#options MAC_BIBA
#options MAC_BSDEXTENDED
#options MAC_DEBUG
#options MAC_IFOFF
#options MAC_LOMAC
#options MAC_MLS
#options MAC_NONE
#options MAC_PARTITION
#options MAC_PORTACL
#options MAC_SEEOTHERUIDS
#options MAC_TEST

## Buses
#--
#options SMP
device  apic
options NO_MIXED_MODE
device  acpi
device  npx
device  isa
device  pci
#device agp

## ISA-Controller
#
device  atkbdc  # AT keyboard controller
device  sio # 8250, 16[45]50 based serial ports
device  pmtimer

## PCI-Controller
#--
device  ata
device  uhci# UHCI PCI-USB interface
device  ohci# OHCI PCI-USB interface

## Devices with their options
#
#+ IDE ++
device  atadisk # ATA disk drives
device  atapicd # ATAPI CDROM drives
options ATA_STATIC_ID   #Static device numbering
options FFS #Berkeley Fast Filesystem
options UDF
options UFS_ACL #Support for access control lists
options UFS_DIRHASH #Improve performance on big directories
options SOFTUPDATES #Enable FFS soft updates support
options GEOM_BDE
options UFS_EXTATTR
options UFS_EXTATTR_AUTOSTART
options QUOTA   #enable disk quotas
#options SUIDDIR
#+ SCSI +
device  scbus   # SCSI bus (required)
device  da  # Direct Access (disks)
device  pass# Passthrough device (direct SCSI access)
#device atapicam
#+ Eingabe +
device  atkbd   # AT keyboard
device  psm # PS/2 mouse
#+ Ausgabe ++
device  vga # VGA video card driver
options VESA
device  splash  # Splash screen and screen saver support
device  sc
options MAXCONS=12
options SC_DISABLE_REBOOT
options SC_PIXEL_MODE
options SC_HISTORY_SIZE=1000
device  pcm
#+ USB +
device  usb # USB Bus (required)
device  ugen# Generic
device  uhid# Human Interface Devices
device  ukbd# Keyboard
device  umass   # Disks/Mass storage - Requires scbus and da
device  ums # Mouse
#+ Netzwerk +
device  miibus  # MII bus support
device  fxp
options DEVICE_POLLING
options INET#InterNETworking
options NFSCLIENT   #Network Filesystem Client
options NFSSERVER   #Network Filesystem Server

Re: kernel panic with todays source

On Sunday 16 November 2003 05:34, Robert Watson wrote:
 On Sun, 16 Nov 2003, Harald Schmalzbauer wrote:
  Fatal trap 12   :page fault while in kernel mode
  fault virtual address   =0x24
  fault code  =supervisor read, page not present
  instruction pointer =0x8:0xc056c706
  stack pointer   =0x10:0xcdca4ca4
  frame pointer   =0x10:0xcdca4ca4
  code segment=base 0x0, limit 0xf, type 0x1b
  =DPL 0, pres 1, def32 1, gran 1
  processor eflags=resume, IOPL=0
  current process =11 (idle)
  trap number =12
  panic: page fault
 
  I do have compiled the kernel with makeoptions debug but I don't have a
  serial terminal nor firewire.

 Could you show the output from running the following command in gdb -k
 kernel.debug:

   l *0xc056c706

 This will tell us where in the kernel the instruction pointer in question
 was.  For whatever reason, your kernel panic doesn't seem to have dropped
 you into DDB (at least, the output looks that way).  If you did get into
 ddb, the results of the trace command would be very helpful.  As you
 have no serial console, it's probably sufficient to just transcript the

I think for this I need to set options DDB in my kernel, don't I? But 
without serial terminal this is pretty useless I think.
But I'll do if you can get needed information which was otherwise not 
accessable.

Thanks,

-Harry

 offsets at the end of each line in the trace (functioname+0xOFFSET)
 without the argument entries.

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


pgp0.pgp
Description: signature

Re: kernel panic with todays source

On Sunday 16 November 2003 05:40, Craig Rodrigues wrote:
 On Sun, Nov 16, 2003 at 05:32:03AM +0100, Harald Schmalzbauer wrote:
  instruction pointer =0x8:0xc056c706
  stack pointer   =0x10:0xcdca4ca4
  frame pointer   =0x10:0xcdca4ca4

 Do you have a file:
 /usr/obj/usr/src/sys/CALE/kernel.debug ?

 If so, if you do:

 gdb -k /usr/obj/usr/src/sys/CALE/kernel.debug

 What do you see if you do:
 l *0xc056c706

(kgdb) l *0xc056c706
0xc056c706 is in vsscanf (/usr/src/sys/kern/subr_scanf.c:224).
219
220 case '[':
221 fmt = __sccl(ccltab, fmt);
222 flags |= NOSKIP;
223 c = CT_CCL;
224 break;
225
226 case 'c':
227 flags |= NOSKIP;
228 c = CT_CHAR;

 l *0xcdca4ca4

(kgdb) l *0xcdca4ca4
No source file for address 0xcdca4ca4

 l *0xcdca4ca4

Sorry, perhaps I mistyped that address. If it helps, I could reboot with the 
faulty kernel and look for the address again.

Thanks,

-Harry




pgp0.pgp
Description: signature

Re: kernel panic with todays source

On Sunday 16 November 2003 05:49, Harald Schmalzbauer wrote:
 On Sunday 16 November 2003 05:34, Robert Watson wrote:
  On Sun, 16 Nov 2003, Harald Schmalzbauer wrote:
   Fatal trap 12   :page fault while in kernel mode
   fault virtual address   =0x24
   fault code  =supervisor read, page not present
   instruction pointer =0x8:0xc056c706
   stack pointer   =0x10:0xcdca4ca4
   frame pointer   =0x10:0xcdca4ca4
   code segment=base 0x0, limit 0xf, type 0x1b
   =DPL 0, pres 1, def32 1, gran 1
   processor eflags=resume, IOPL=0
   current process =11 (idle)
   trap number =12
   panic: page fault
  
   I do have compiled the kernel with makeoptions debug but I don't have a
   serial terminal nor firewire.
 
  Could you show the output from running the following command in gdb -k
  kernel.debug:
 
l *0xc056c706

Sorry, forgot to mention that I answered this in Craig Rodrigues mail. But 
while I'm here:

(kgdb) l *0xc056c706
0xc056c706 is in vsscanf (/usr/src/sys/kern/subr_scanf.c:224).
219
220 case '[':
221 fmt = __sccl(ccltab, fmt);
222 flags |= NOSKIP;
223 c = CT_CCL;
224 break;
225
226 case 'c':
227 flags |= NOSKIP;
228 c = CT_CHAR;

Thanks,

-Harry

 
  This will tell us where in the kernel the instruction pointer in question
  was.  For whatever reason, your kernel panic doesn't seem to have dropped
  you into DDB (at least, the output looks that way).  If you did get into
  ddb, the results of the trace command would be very helpful.  As you
  have no serial console, it's probably sufficient to just transcript the

 I think for this I need to set options DDB in my kernel, don't I? But
 without serial terminal this is pretty useless I think.
 But I'll do if you can get needed information which was otherwise not
 accessable.

 Thanks,

 -Harry

  offsets at the end of each line in the trace (functioname+0xOFFSET)
  without the argument entries.
 
  Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
  [EMAIL PROTECTED]  Network Associates Laboratories


pgp0.pgp
Description: signature

Re: ULE and very bad responsiveness

2003-11-13 Thread Harald Schmalzbauer

On Thursday 13 November 2003 22:25, Jeff Roberson wrote:
 On Thu, 13 Nov 2003, Harald Schmalzbauer wrote:
  On Thursday 13 November 2003 07:17, Harald Schmalzbauer wrote:
   Hi,
  
   from comp.unix.bsd.freebsd.misc:
  
   Kris Kennaway wrote:
On 2003-11-13, Harald Schmalzbauer [EMAIL PROTECTED] wrote:
Well, I don't have any measurements but in my case it's not
neccessary at all. I built a UP kernel with ULE like Kris advised
me.
   
Are you running an up-to-date 5.1-CURRENT?  ULE was broken with these
characteristics until very recently.  If you're up-to-date and still
see these problems, you need to post to the current mailing list.
   
Kris
  
   Yes, I am running current as of 13. Nov.
  
   Find attached my first problem description.
 
  This time I also attached my dmesg and kernel conf

 Try running seti with nice +20 rather than 15.  Do you experience bad
 interactivity without seti running?

No, without seti everythin seems to be fine except that I cannot watch two 
movies at the same time which is no problem with the old scheduler. I already 
switched back from ULE to the old because at the moment ULE makes working 
exhausting.
I also could play quake(2) and have something compiling in the background but 
I see every new object file in form of a picture freeze. Also every other 
disk access seems to block the whole machine for a moment.
I'll try again if somebody has an idea what's wrong. Then I can try running 
seti wtih nice 20 but that's not really a solution. It's working perfectly 
with nice 15 and the old scheduler.

Thanks,

-Harry


 Thanks,
 Jeff

   Thanks,
  
   -Harry

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


pgp0.pgp
Description: signature

Re: which 3ware controllers are supported ?

2003-11-12 Thread Harald Schmalzbauer

On Wednesday 12 November 2003 14:07, Andrew Atrens wrote:
 Anyone using a 3WARE ESCALADE 7500-4LP ATA RAID CARD ?

I recommended that a friend of mine. It's running without an Problem under 
4.7. I Don't know about newer versions but it should work well.

-Harry



 Cheers,

 Andrew.



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


pgp0.pgp
Description: signature

ULE and very bad responsiveness

2003-11-12 Thread Harald Schmalzbauer

Hi,

from comp.unix.bsd.freebsd.misc:

Kris Kennaway wrote:

 On 2003-11-13, Harald Schmalzbauer [EMAIL PROTECTED] wrote:
 
 Well, I don't have any measurements but in my case it's not neccessary at
 all. I built a UP kernel with ULE like Kris advised me.
 
 Are you running an up-to-date 5.1-CURRENT?  ULE was broken with these
 characteristics until very recently.  If you're up-to-date and still
 see these problems, you need to post to the current mailing list.
 
 Kris

Yes, I am running current as of 13. Nov.

Find attached my first problem description.

Thanks,

-Harry
---BeginMessage---
Harald Schmalzbauer wrote:

 Kris Kennaway wrote:
 
 On 2003-11-12, Ivan Voras [EMAIL PROTECTED] wrote:
 Kris Kennaway wrote:
 On 2003-11-11, Ivan Voras [EMAIL PROTECTED] wrote:

 Debugging in 5-current halves the overall performance for non
 cpu-only processes and ULE scheduler still offers less performance
 than 4BSD.

 No, your data shows no statistically-significant difference between
 ULE and 4BSD.

 Well, I agree 6 measurements[*] are not much, but then again, it points
 to a correlation and some folks need all the speed they can get (and
 don't have MP systems).


 [*] bytebench runs 6 measurements for each test.
 
 There's no correlation unless you do enough measurements to measure
 it.  Your numbers showed an tiny difference which may or may not be
 real.
 
 Well, I don't have any measurements but in my case it's not neccessary at
 all. I built a UP kernel with ULE like Kris advised me.
 Seti is always running with nice 15.
 When I try to install a already built (compiled) port it takes about 2
 minutes to complete (in this case the nvidia-driver).
 When I stop seti it is done in about 5 Seconds like usual. Also when
 building a port, the first make-fetch-extract-patch-configure steps take
 100 times the time against seti not running.
 With the old scheduler I dind't even recognize that seti was running
 (that's what nice 15 should affect I think).
 On the other hand, starting up kde doesn't make any noticable difference,
 but starting (and working) with kmail does. It's not the factor 100 or so
 like with the make process but noticably more sluggish where I couldn't
 feel any difference with the old scheduler.
 
 Please tell me what I should do. If there's no solution I'll switch back
 in a view days because I loved BSD for the great responsiveness under high
 load. I always had seti runnning, compiling in the backgroung, listening
 music and do my daily work without any problem on a 1Ghz machine.
 
 Thanks,
 
 -Harry
 
 
 
 
 Kris

---End Message---


pgp0.pgp
Description: signature

Re: ULE and very bad responsiveness

2003-11-12 Thread Harald Schmalzbauer

On Thursday 13 November 2003 07:17, Harald Schmalzbauer wrote:
 Hi,

 from comp.unix.bsd.freebsd.misc:

 Kris Kennaway wrote:
  On 2003-11-13, Harald Schmalzbauer [EMAIL PROTECTED] wrote:
  Well, I don't have any measurements but in my case it's not neccessary
  at all. I built a UP kernel with ULE like Kris advised me.
 
  Are you running an up-to-date 5.1-CURRENT?  ULE was broken with these
  characteristics until very recently.  If you're up-to-date and still
  see these problems, you need to post to the current mailing list.
 
  Kris

 Yes, I am running current as of 13. Nov.

 Find attached my first problem description.

This time I also attached my dmesg and kernel conf


 Thanks,

 -Harry
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 #39: Thu Nov 13 04:47:34 CET 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE
Preloaded elf kernel /boot/kernel/kernel at 0xc09bf000.
Preloaded elf module /boot/kernel/linux.ko at 0xc09bf244.
Preloaded elf module /boot/kernel/nvidia.ko at 0xc09bf2f0.
ACPI APIC Table: D815EA EA81510A
Timecounter i8254 frequency 1183583 Hz quality 0
CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.83-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x6b1  Stepping = 1
  
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 268173312 (255 MB)
avail memory = 250781696 (239 MB)
ioapic0: Changing APIC ID to 1
ioapic0 Version 2.0 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc0760fe2 (122)
VESA: NVIDIA
acpi0: D815EA D815EPFV on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 12 entries at 0xc00f2a10
acpi0: Power Button (fixed)
Timecounter ACPI-safe frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0: CPU port 0x530-0x537 on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci2: PCI bus on pcib1
pcib1: slot 0 INTA is routed to irq 16
nvidia0: GeForce4 MX 440 with AGP8X mem 0xf000-0xf3ff,0xfd00-0xfdff 
irq 16 at device 0.0 on pci2
pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0
pci1: ACPI PCI bus on pcib2
fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xdf00-0xdf3f mem 
0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1
fxp0: Ethernet address 00:03:47:f0:c2:ef
miibus0: MII bus on fxp0
inphy0: i82562ET 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH2 UDMA100 controller port 0xffa0-0xffaf at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xef40-0xef5f irq 19 at 
device 31.2 on pci0
usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ichsmb0: Intel 82801BA (ICH2) SMBus controller port 0xefa0-0xefaf irq 17 at device 
31.3 on pci0
smbus0: System Management Bus on ichsmb0
smb0: SMBus generic I/O on smbus0
uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xef80-0xef9f irq 23 at 
device 31.4 on pci0
usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub2: Standard Microsystems product 0x0140, class 9/0, rev 1.10/0.00, addr 2
uhub2: 4 ports with 4 removable, self powered
ums0: Microsoft Microsoft IntelliMouse® Explorer, rev 1.10/1.14, addr 3, iclass 3/1
ums0: 5 buttons and Z dir.
uhub3: Texas Instruments General Purpose USB Hub, class 9/0, rev 1.10/1.01, addr 4
uhub3: 2 ports with 2 removable, bus powered
pcm0: Intel ICH2 (82801BA) port 0xef00-0xef3f,0xe800-0xe8ff irq 17 at device 31.5 on 
pci0
pcm0: Analog Devices AD1885 AC97 Codec
atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 
0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
orm0: Option ROMs at iomem 0xd0800-0xd17ff,0xcf800-0xd07ff on isa0
pmtimer0 on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 12 virtual consoles, flags=0x300
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa

Re: APIC-UP related panic

2003-11-10 Thread Harald Schmalzbauer

On Monday 10 November 2003 19:33, John Baldwin wrote:
 On 08-Nov-2003 Harald Schmalzbauer wrote:
  On Thursday 06 November 2003 17:33, John Baldwin wrote:
  On 06-Nov-2003 Harald Schmalzbauer wrote:
   Hello,
  
   I have one reproducable panic with sources from 04. Nov when enabling
   device apic in the kernel.
   While building OpenOffice about 1 1/2 hours after start the system
   reboots. This is absolutely reproducable. Removing device apic from
   the kernel solves the problem!
*SNIP*
  Can you try the patch at
  http://www.FreeBSD.org/~jhb/patches/spurious.patch
 
  Regrettably this hasn't helped. The machine crashed aigain when building
  OpenOffice. This time I have something different in messages:
  Nov  7 19:51:27 cale syslogd: kernel boot file is /boot/kernel/kernel
  Nov  7 19:51:27 cale kernel: panic: Couldn't get vector from ISR!
  Nov  7 19:51:27 cale kernel:
  Nov  7 19:51:27 cale kernel: syncing disks, buffers remaining... 2202
  2202 2202 2202 2202 2202 2202
  2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202
  Nov  7 19:51:27 cale kernel: giving up on 1109 buffers
  Nov  7 19:51:27 cale kernel: Uptime: 3h57m51s
  Nov  7 19:51:27 cale kernel: Shutting down ACPI
  Nov  7 19:51:27 cale kernel: Automatic reboot in 15 seconds - press a key
  on the console to abort
  Nov  7 19:51:27 cale kernel: Rebooting...
 
  Let me know if I can help. Should I build a debug-kernel? I think that
  doesn't help too much since the machine rebootos immediately, so I have
  no chance to type anything like trace.

 Ok.  The problem is that when the spurious interrupt is triggered, it
 doesn't set a bit in the ISR.  Hmm, can you try using 'options
 NO_MIXED_MODE' instead?

Uhm, I don't really understand what's going on. Also I haven't found anything 
about NO_MIXED_MODE but I made the usual kernel (-current from Nov.09, 
without the spurious patch) with device apic and options NO_MIXED_MODE.
Now quake2forge compiled successfully (which also crashed the machine with the 
last apic kernel) also OpenOffice compiles fine.
I see one difference in dmesg:
Timecounter shows now ACPI-fast like with a previous SMP-kernel instead of 
ACPI-safe like wth the UP kernel. Just for info attached the new dmesg.


Do you have any enlightning link for me about apic and NO_MIXED_MODE?

Thanks a lot,

-Harry


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 #37: Tue Nov 11 01:20:26 CET 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE
Preloaded elf kernel /boot/kernel/kernel at 0xc09c1000.
Preloaded elf module /boot/kernel/linux.ko at 0xc09c1244.
Preloaded elf module /boot/kernel/nvidia.ko at 0xc09c12f0.
ACPI APIC Table: D815EA EA81510A
Timecounter i8254 frequency 1183579 Hz quality 0
CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.82-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x6b1  Stepping = 1
  
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 268173312 (255 MB)
avail memory = 250781696 (239 MB)
ioapic0: Changing APIC ID to 1
ioapic0 Version 2.0 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc07603e2 (122)
VESA: NVIDIA
acpi0: D815EA D815EPFV on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 12 entries at 0xc00f2a10
acpi0: Power Button (fixed)
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0: CPU port 0x530-0x537 on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci2: PCI bus on pcib1
pcib1: slot 0 INTA is routed to irq 16
nvidia0: GeForce4 MX 440 with AGP8X mem 0xf000-0xf3ff,0xfd00-0xfdff 
irq 16 at device 0.0 on pci2
pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0
pci1: ACPI PCI bus on pcib2
fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xdf00-0xdf3f mem 
0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1
fxp0: Ethernet address 00:03:47:f0:c2:ef
miibus0: MII bus on fxp0
inphy0: i82562ET 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH2 UDMA100 controller port 0xffa0-0xffaf at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xef40-0xef5f irq 19 at 
device 31.2 on pci0
usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ichsmb0: Intel 82801BA (ICH2) SMBus controller port

Re: APIC-UP related panic

2003-11-07 Thread Harald Schmalzbauer

On Thursday 06 November 2003 17:33, John Baldwin wrote:
 On 06-Nov-2003 Harald Schmalzbauer wrote:
  Hello,
 
  I have one reproducable panic with sources from 04. Nov when enabling
  device apic in the kernel.
  While building OpenOffice about 1 1/2 hours after start the system
  reboots. This is absolutely reproducable. Removing device apic from the
  kernel solves the problem!
  The only thing I have are these lines from /var/log/messages:
  (attached the different dmesgs)
 
  Nov  5 13:41:40 cale syslogd: kernel boot file is /boot/kernel/kernel
  Nov  5 13:41:40 cale kernel: instruction pointer= 0x8:0xc054c85d
  Nov  5 13:41:40 cale kernel: stack pointer  = 0x10:0xcdc9dbe0
  Nov  5 13:41:40 cale kernel: frame pointer  = 0x10:0xcdc9dbe4
  Nov  5 13:41:40 cale kernel: code segment   = base 0x0, limit
  0xf, type 0x1b
  Nov  5 13:41:40 cale kernel: = DPL 0, pres 1, def32 1, gran 1
  Nov  5 13:41:40 cale kernel: processor eflags   = interrupt enabled, IOPL
  = 0 Nov  5 13:41:40 cale kernel: current process= 26 (irq16:
  nvidia0) Nov  5 13:41:40 cale kernel: trap number= 30
  Nov  5 13:41:40 cale kernel: panic: unknown/reserved trap
  Nov  5 13:41:40 cale kernel:
  Nov  5 13:41:40 cale kernel: syncing disks, buffers remaining... 2202
  2202 2202 2202 2202 2202 2202
  2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202
  Nov  5 13:41:40 cale kernel: giving up on 1022 buffers
  Nov  5 13:41:40 cale kernel: Uptime: 1h38m28s
  Nov  5 13:41:40 cale kernel: Shutting down ACPI
  Nov  5 13:41:40 cale kernel: stray irq9
  Nov  5 13:41:40 cale kernel: Automatic reboot in 15 seconds - press a key
  on the console to abort
  Nov  5 13:41:40 cale kernel: Rebooting...

 Can you try the patch at http://www.FreeBSD.org/~jhb/patches/spurious.patch

Regrettably this hasn't helped. The machine crashed aigain when building 
OpenOffice. This time I have something different in messages:
Nov  7 19:51:27 cale syslogd: kernel boot file is /boot/kernel/kernel
Nov  7 19:51:27 cale kernel: panic: Couldn't get vector from ISR!
Nov  7 19:51:27 cale kernel:
Nov  7 19:51:27 cale kernel: syncing disks, buffers remaining... 2202 2202 
2202 2202 2202 2202 2202
2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202
Nov  7 19:51:27 cale kernel: giving up on 1109 buffers
Nov  7 19:51:27 cale kernel: Uptime: 3h57m51s
Nov  7 19:51:27 cale kernel: Shutting down ACPI
Nov  7 19:51:27 cale kernel: Automatic reboot in 15 seconds - press a key on 
the console to abort
Nov  7 19:51:27 cale kernel: Rebooting...

Let me know if I can help. Should I build a debug-kernel? I think that doesn't 
help too much since the machine rebootos immediately, so I have no chance to 
type anything like trace.

-Harry



pgp0.pgp
Description: signature

APIC-UP related panic

2003-11-06 Thread Harald Schmalzbauer

Hello,

I have one reproducable panic with sources from 04. Nov when enabling device 
apic in the kernel.
While building OpenOffice about 1 1/2 hours after start the system reboots. 
This is absolutely reproducable. Removing device apic from the kernel solves 
the problem!
The only thing I have are these lines from /var/log/messages:
(attached the different dmesgs)

Nov  5 13:41:40 cale syslogd: kernel boot file is /boot/kernel/kernel
Nov  5 13:41:40 cale kernel: instruction pointer= 0x8:0xc054c85d
Nov  5 13:41:40 cale kernel: stack pointer  = 0x10:0xcdc9dbe0
Nov  5 13:41:40 cale kernel: frame pointer  = 0x10:0xcdc9dbe4
Nov  5 13:41:40 cale kernel: code segment   = base 0x0, limit 
0xf, type 0x1b
Nov  5 13:41:40 cale kernel: = DPL 0, pres 1, def32 1, gran 1
Nov  5 13:41:40 cale kernel: processor eflags   = interrupt enabled, IOPL = 0
Nov  5 13:41:40 cale kernel: current process= 26 (irq16: nvidia0)
Nov  5 13:41:40 cale kernel: trap number= 30
Nov  5 13:41:40 cale kernel: panic: unknown/reserved trap
Nov  5 13:41:40 cale kernel:
Nov  5 13:41:40 cale kernel: syncing disks, buffers remaining... 2202 2202 
2202 2202 2202 2202 2202
2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202
Nov  5 13:41:40 cale kernel: giving up on 1022 buffers
Nov  5 13:41:40 cale kernel: Uptime: 1h38m28s
Nov  5 13:41:40 cale kernel: Shutting down ACPI
Nov  5 13:41:40 cale kernel: stray irq9
Nov  5 13:41:40 cale kernel: Automatic reboot in 15 seconds - press a key on 
the console to abort
Nov  5 13:41:40 cale kernel: Rebooting...
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 #28: Tue Nov  4 22:18:02 CET 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE
Preloaded elf kernel /boot/kernel/kernel at 0xc09c1000.
Preloaded elf module /boot/kernel/linux.ko at 0xc09c1244.
Preloaded elf module /boot/kernel/nvidia.ko at 0xc09c12f0.
ACPI APIC Table: D815EA EA81510A
Timecounter i8254 frequency 1183576 Hz quality 0
CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.82-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x6b1  Stepping = 1
  
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 268173312 (255 MB)
avail memory = 250781696 (239 MB)
ioapic0: Changing APIC ID to 1
ioapic0 Version 2.0 irqs 0-23 on motherboard
Pentium Pro MTRR support enabled
VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc07600e2 (122)
VESA: NVIDIA
acpi0: D815EA D815EPFV on motherboard
pcibios: BIOS version 2.10
Using $PIR table, 12 entries at 0xc00f2a10
acpi0: Power Button (fixed)
Timecounter ACPI-safe frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0
acpi_cpu0: CPU port 0x530-0x537 on acpi0
acpi_button0: Power Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci2: PCI bus on pcib1
pcib1: slot 0 INTA is routed to irq 16
nvidia0: GeForce4 MX 440 with AGP8X mem 0xf000-0xf3ff,0xfd00-0xfdff 
irq 16 at device 0.0 on pci2
pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0
pci1: ACPI PCI bus on pcib2
fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xdf00-0xdf3f mem 
0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1
fxp0: Ethernet address 00:03:47:f0:c2:ef
miibus0: MII bus on fxp0
inphy0: i82562ET 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH2 UDMA100 controller port 0xffa0-0xffaf at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xef40-0xef5f irq 19 at 
device 31.2 on pci0
usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ichsmb0: Intel 82801BA (ICH2) SMBus controller port 0xefa0-0xefaf irq 17 at device 
31.3 on pci0
smbus0: System Management Bus on ichsmb0
smb0: SMBus generic I/O on smbus0
uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xef80-0xef9f irq 23 at 
device 31.4 on pci0
usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub2: Standard Microsystems product 0x0140, class 9/0, rev 1.10/0.00, addr 2
uhub2: 4 ports with 4 removable, self powered
ums0: Microsoft Microsoft IntelliMouse® Explorer, rev 1.10/1.14, addr 3, iclass 3/1
ums0: 5 buttons and Z dir.
uhub3: Texas Instruments General Purpose USB Hub, class 9/0, rev 1.10/1.01,

Re: APIC-UP related panic

2003-11-06 Thread Harald Schmalzbauer

On Thursday 06 November 2003 17:33, John Baldwin wrote:
 On 06-Nov-2003 Harald Schmalzbauer wrote:
*SCHNIP*
  Nov  5 13:41:40 cale kernel: processor eflags   = interrupt enabled, IOPL
  = 0 Nov  5 13:41:40 cale kernel: current process= 26 (irq16:
  nvidia0) Nov  5 13:41:40 cale kernel: trap number= 30
  Nov  5 13:41:40 cale kernel: panic: unknown/reserved trap
  Nov  5 13:41:40 cale kernel:
  Nov  5 13:41:40 cale kernel: syncing disks, buffers remaining... 2202
  2202 2202 2202 2202 2202 2202
  2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202 2202
  Nov  5 13:41:40 cale kernel: giving up on 1022 buffers
  Nov  5 13:41:40 cale kernel: Uptime: 1h38m28s
  Nov  5 13:41:40 cale kernel: Shutting down ACPI
  Nov  5 13:41:40 cale kernel: stray irq9
  Nov  5 13:41:40 cale kernel: Automatic reboot in 15 seconds - press a key
  on the console to abort
  Nov  5 13:41:40 cale kernel: Rebooting...

 Can you try the patch at http://www.FreeBSD.org/~jhb/patches/spurious.patch

It's my pleasure to do so, but these days I have to move some furniture to pay 
my rent.
Expect feedback at ~Sat., 15.00 UTC. I hope so.

Thanks a lot,

-Harry


pgp0.pgp
Description: signature

New PNP0303 and aPic question

Hi all,

with today's -current (with the new irq stuff) I get the following messages 
wich I haven't had before:
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
unknown: PNP0303 can't assign resources (port)
unknown: PNP0501 can't assign resources (port)
unknown: PNP0501 can't assign resources (port)
unknown: PNP0700 can't assign resources (port)
Timecounter TSC frequency 1095821276 Hz quality 800

See attached the complete dmesg.


Then I have a question regarding the aPic: I know that my hardware has such a 
aPic and under WinXP there were irqs assigned up to ~23.
Is it possible to support that apic without SMP?

Thanks,

-Harry


pgp0.pgp
Description: signature

Re: New PNP0303 and aPic question

On Tuesday 04 November 2003 17:10, Harald Schmalzbauer wrote:
 Hi all,

 with today's -current (with the new irq stuff) I get the following messages
 wich I haven't had before:
 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
 unknown: PNP0303 can't assign resources (port)
 unknown: PNP0501 can't assign resources (port)
 unknown: PNP0501 can't assign resources (port)
 unknown: PNP0700 can't assign resources (port)
 Timecounter TSC frequency 1095821276 Hz quality 800

Mist, now it really is attached.

Sorry


 See attached the complete dmesg.


 Then I have a question regarding the aPic: I know that my hardware has such
 a aPic and under WinXP there were irqs assigned up to ~23.
 Is it possible to support that apic without SMP?

 Thanks,

 -Harry
and installed have the same CVS Id, deleting
Waiting (max 60 seconds) for system process `vnlru' to stop...stopped
Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped
Waiting (max 60 seconds) for system process `syncer' to stop...stopped

syncing disks, buffers remaining... 14 14 
done
Uptime: 4h56m24s
Shutting down ACPI
Rebooting...
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 #27: Tue Nov  4 16:37:45 CET 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE
Preloaded elf kernel /boot/kernel/kernel at 0xc0974000.
Preloaded elf module /boot/kernel/linux.ko at 0xc0974244.
Preloaded elf module /boot/kernel/nvidia.ko at 0xc09742f0.
Timecounter i8254 frequency 1183580 Hz quality 0
CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.82-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x6b1  Stepping = 1
  
Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory  = 268173312 (255 MB)
avail memory = 250789888 (239 MB)
Pentium Pro MTRR support enabled
VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc0720ae2 (122)
VESA: NVIDIA
npx0: [FAST]
npx0: math processor on motherboard
npx0: INT 16 interface
pcibios: BIOS version 2.10
Using $PIR table, 12 entries at 0xc00f2a10
pcib0: Intel 82815 (i815 GMCH) Host To Hub bridge at pcibus 0 on motherboard
pci0: PCI bus on pcib0
pci_cfgintr: 0:31 INTD BIOS irq 7
pci_cfgintr: 0:31 INTB BIOS irq 9
pci_cfgintr: 0:31 INTC BIOS irq 10
pci_cfgintr: 0:31 INTB BIOS irq 9
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci2: PCI bus on pcib1
pci_cfgintr: 0:1 INTA routed to irq 4
pcib1: slot 0 INTA is routed to irq 4
nvidia0: GeForce4 MX 440 with AGP8X mem 0xf000-0xf3ff,0xfd00-0xfdff 
irq 4 at device 0.0 on pci2
pcib2: PCIBIOS PCI-PCI bridge at device 30.0 on pci0
pci1: PCI bus on pcib2
pci_cfgintr: 1:8 INTA BIOS irq 11
fxp0: Intel 82801BA/CAM (ICH2/3) Pro/100 Ethernet port 0xdf00-0xdf3f mem 
0xfc9ff000-0xfc9f irq 11 at device 8.0 on pci1
fxp0: Ethernet address 00:03:47:f0:c2:ef
miibus0: MII bus on fxp0
inphy0: i82562ET 10/100 media interface on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH2 UDMA100 controller port 0xffa0-0xffaf at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata0: [MPSAFE]
ata1: at 0x170 irq 15 on atapci0
ata1: [MPSAFE]
uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xef40-0xef5f irq 7 at 
device 31.2 on pci0
usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0
usb0: USB revision 1.0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
ichsmb0: Intel 82801BA (ICH2) SMBus controller port 0xefa0-0xefaf irq 9 at device 
31.3 on pci0
smbus0: System Management Bus on ichsmb0
smb0: SMBus generic I/O on smbus0
uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xef80-0xef9f irq 10 at 
device 31.4 on pci0
usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1
usb1: USB revision 1.0
uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
uhub2: Standard Microsystems product 0x0140, class 9/0, rev 1.10/0.00, addr 2
uhub2: 4 ports with 4 removable, self powered
ums0: Microsoft Microsoft IntelliMouse® Explorer, rev 1.10/1.14, addr 3, iclass 3/1
ums0: 5 buttons and Z dir.
uhub3: Texas Instruments General Purpose USB Hub, class 9/0, rev 1.10/1.01, addr 4
uhub3: 2 ports with 2 removable, bus powered
pcm0: Intel ICH2 (82801BA) port 0xef00-0xef3f,0xe800-0xe8ff irq 9 at device 31.5 on 
pci0
pcm0: Analog Devices AD1885 AC97 Codec
orm0: Option ROMs at iomem 0xd0800-0xd17ff,0xcf800-0xd07ff on isa0
pmtimer0 on isa0
atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 
0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: 1440-KB 3.5 drive on fdc0 drive 0

Re: new interrupt code: panic when going multiuser

On Tuesday 04 November 2003 18:19, John Baldwin wrote:
 On 04-Nov-2003 Lukas Ertl wrote:
  On Tue, 4 Nov 2003, John Baldwin wrote:
  On 04-Nov-2003 Lukas Ertl wrote:
   On Tue, 4 Nov 2003, Lukas Ertl wrote:
   I somehow can't get at a good vmcore :-(.  But I found out that the
   machine boots fine in Safe Mode, where DMA and hw.ata.wc is turned
   off.
  
   Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine.  Could
   there be some issue with ATAng + new interrupt code?
 
  Can you provide a dmesg please?  There may be a weird issue with
  some PPro's for example that I haven't been able to test.
 
  Sorry for the noise, I think I found the problem: I had to put options
  SMP and device apic into the kernel, now everythings seems to run
  fine. I thought they were only needed for SMP kernels, that's at least
  what the comment in GENERIC says...  If you still want the dmesg, I can
  send it to you.

 Well, a kernel without SMP and just 'device apic' should work fine, and
 a kernel with both SMP and 'device apic' should also work fine.

Hmm, I think this answer should be for New PNP0303 and aPic question?

Well I tired to build one (with -curr some weeks ago) with device apic only 
which didn't work, I had to add options smp arrrgghhh. Had a look in my file 
and saw I did the following:
#options SMP
#options APIC_IO

Seems I didn't use device apic (perhaps I didn't recognize)

But regardless, when I built a SMP kernel it didn't run on my UP machine.

Thanks a lot,

-Harry


pgp0.pgp
Description: signature

Re: new interrupt code: panic when going multiuser

On Tuesday 04 November 2003 19:38, John Baldwin wrote:
 On 04-Nov-2003 Harald Schmalzbauer wrote:
  On Tuesday 04 November 2003 18:19, John Baldwin wrote:
  On 04-Nov-2003 Lukas Ertl wrote:
   On Tue, 4 Nov 2003, John Baldwin wrote:
   On 04-Nov-2003 Lukas Ertl wrote:
On Tue, 4 Nov 2003, Lukas Ertl wrote:
I somehow can't get at a good vmcore :-(.  But I found out that
the machine boots fine in Safe Mode, where DMA and hw.ata.wc is
turned off.
   
Ok, if I set hw.ata.ata_dma=0 in loader.conf, it boots fine.  Could
there be some issue with ATAng + new interrupt code?
  
   Can you provide a dmesg please?  There may be a weird issue with
   some PPro's for example that I haven't been able to test.
  
   Sorry for the noise, I think I found the problem: I had to put
   options SMP and device apic into the kernel, now everythings seems
   to run fine. I thought they were only needed for SMP kernels, that's
   at least what the comment in GENERIC says...  If you still want the
   dmesg, I can send it to you.
 
  Well, a kernel without SMP and just 'device apic' should work fine, and
  a kernel with both SMP and 'device apic' should also work fine.
 
  Hmm, I think this answer should be for New PNP0303 and aPic question?
 
  Well I tired to build one (with -curr some weeks ago) with device apic
  only which didn't work, I had to add options smp arrrgghhh. Had a look in
  my file and saw I did the following:
 #options SMP
 #options APIC_IO
 
  Seems I didn't use device apic (perhaps I didn't recognize)
 
  But regardless, when I built a SMP kernel it didn't run on my UP machine.
 
  Thanks a lot,

 I just committed a bunch of changes to the interrupt and SMP code.
 When you update to those changes, you should be able to build a UP
 kernel with 'device apic' and have it work, and you should be able
 to build an SMP kernel and have it run on your machine.

Oh, great! Thanks a lot and sorry for the former nonses-reply. I read your 
first answer which was correct for my subject but I hadn't carefully read 
this thread.
After jdk14 is finished I'll recvsup and build a new kernel. I already built 
world today so I hope kernel only is okay.

Best regards,

-Harry


pgp0.pgp
Description: signature

hw.ata.atapi_dma problem

Salve,

with today's -current (~21:30 UTC) I get hw.ata.atapi_dma listed again. But 
it's said to be 1 so dma should be enabled I think.
dmesg says:
Timecounters tick every 1.000 msec
GEOM: create disk ad0 dp=0xc2d97570
ad0: 39083MB Maxtor 4D040H2 [79408/16/63] at ata0-master UDMA100
acd0: CDROM SONY CDU4811 at ata1-master PIO4
pcm0: measured ac97 link rate at 55928 Hz

So dma is NOT enabled although the sysctl is 1

atacontrol mode 1 also tells PIO4
After atacontrol mode 1 udma33 udma33 I get udma33 returned.

So whats's the truth? I think my cd-rom should be able to work in dma mode.
Mode tells me no dma is used and sysctl the opposite.
Of course I have the sysctl enabled in loader.conf!

Thanks,

-Harry


pgp0.pgp
Description: signature

Re: hw.ata.atapi_dma problem

On Tuesday 04 November 2003 23:11, Lukas Ertl wrote:
 On Tue, 4 Nov 2003, Harald Schmalzbauer wrote:
  ad0: 39083MB Maxtor 4D040H2 [79408/16/63] at ata0-master UDMA100
  acd0: CDROM SONY CDU4811 at ata1-master PIO4
 
  So dma is NOT enabled although the sysctl is 1

 For ATAPI devices you need hw.ata.atapi_dma=1.

That's exactly what one line shows in my loader.conf
And sysctl hw.ata.atapi_dma returns 1.
But atacontrol mode 1 tells me PIO4
And also dmesg tells me PIO4!
That's the problem!

-Harry


 regards,
 le


pgp0.pgp
Description: signature

panic with today's -current