Bug reminder, KBDMUX_DFLT_KEYMAP + option *KB*_DFLT_KEYMAP and *map.h in sys/conf/files
Hello, since 10.2 code freeze will start in a week, I'd like to ask if somebody can have a look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865 + https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193817 Short summary: Defining ..._DFLT_KEYMAP should work sc(4)/vt(4) source/target independent (currently if you have a vt(4) driven building machine you can't build a sc(4) kernel with a non-default "sc" keymap) Also, KBDMUX_DFLT_KEYMAP shloud be made available, like we've had ATKBD_DFLT_KEYMAP and UKBD_DFLT_KEYMAP for a very long time, but truned useless since kbdmux(4) was enabled by default long time ago! Lost discussion was started here: https://lists.freebsd.org/pipermail/freebsd-stable/2014-September/080104.html Thanks, -Harry signature.asc Description: OpenPGP digital signature
SLR140 with new mt(1) [Was: Re: sa(4) driver changes available for test]
Bezüglich Kenneth D. Merry's Nachricht vom 28.02.2015 01:08 (localtime): … >> Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2, >> LTO3 and DDS5) >> With DDS5, densitiy is reported as "unknown". If I remember correctly, >> you have your DDS4 reporting "DDS4"? > That means that we need to add DDS5 to the density table in libmt. Can > you send the output of 'mt status -v'? It would actually be helpful for > all three drives. Hello, I'd like to present some test results. All tests were done with 10-stable-r273923 and Ken's sa_driver_changes-patchset, reduced by the commited scsi-sys-code. Unfortunately, there's a problem with appending files to any SLRtape. I can write the first file, but trying to open a second file for writing, results in "end of device" message. This problem doesn't exist for other drives (tested on VXA-2 (also SCSI-2) and DAT72 (SCSI-3)) with exactly same environment (all currently connected SCSI drives (7) are on one mpt(4) bus). After the first "end of device" message, consecutive write attempts lead to "Operation not permitted". According to the datasheet (http://www.tandbergdata.ru/products/files/SLR140_DS_605_ENG.pdf), the drive should speak SCSI-3, but camcontrol shows SCSI-2. ## TandbergData SLR140 Drive ## camcontrol inq $TAPE -v pass3: Removable Sequential Access SCSI-2 device pass3: Serial Number SN140253489 pass3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Command Queueing Enabled Density 0x36 = ALRF-6, 186000 bpi, SLR140 drive + SLR140tape: SLRtape140 (8mm DualReel, 70GB native, 505.9m length, 5.5MiB/s) mt status -v Drive: sa3: Serial Number: SN140253489 - Mode Density Blocksize bpi Compression Current: 0x36:UNKNOWN variable 0 enabled (0x3) - Current Driver State: at rest. - Partition: 0 Calc File Number: 0 Calc Record Number: 0 Residual: 0 Reported File Number: -1 Reported Record Number: -1 Flags: None - Tape I/O parameters: Maximum I/O size allowed by driver and controller (maxio): 131072 bytes Maximum I/O size reported by controller (cpi_maxio): 131072 bytes Maximum block size supported by tape drive and media (max_blk): 262144 bytes Minimum block size supported by tape drive and media (min_blk): 1 bytes Block granularity supported by tape drive and media (blk_gran): 0 bytes Maximum possible I/O size (max_effective_iosize): 131072 bytes Minimum blocksize to reach highest throughput, thus sustained write of uncompressable data (from /dev/random): 24k@5.5MiB/s mt status - Current Driver State: at rest. - Partition: 0 Calc File Number: 1 Calc Record Number: 0 Residual: 0 Reported File Number: -1 Reported Record Number: -1 Flags: None "short READ POSITION" camcontrol cmd $TAPE -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - | hd 30 00 00 00 00 00 06 83 00 00 00 00 00 00 00 00 |0...| 0010 00 00 00 00 || 0014 "vendor READ POSITION" camcontrol cmd $TAPE -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - | hd camcontrol: error sending command (pass3:mpt1:0:13:0): READ POSITION. CDB: 34 01 00 00 00 00 00 00 00 00 (pass3:mpt1:0:13:0): CAM status: SCSI Status Error (pass3:mpt1:0:13:0): SCSI status: Check Condition (pass3:mpt1:0:13:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (pass3:mpt1:0:13:0): Command byte 1 bit 0 is invalid "long READ POSITION" camcontrol cmd $TAPE -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd camcontrol: error sending command (pass3:mpt1:0:13:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00 (pass3:mpt1:0:13:0): CAM status: SCSI Status Error (pass3:mpt1:0:13:0): SCSI status: Check Condition (pass3:mpt1:0:13:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field in CDB) (pass3:mpt1:0:13:0): Command byte 1 bit 2 is invalid Different tapes -- Density 0x34 = ALRF-1, 15400 bpi: SLRtape100 (8mm DualReel, 50GB native, 457.2m length, 4.7MiB/s) SLRtape40 (8mm DualReel, 20GB native, 187,5m length, 4.7MiB/s) Mode Density Blocksize bpi Compression Current: 0x36:UNKNOWN variable 0 enabled (0x3) Density 0x30 = MLR3, 103124 bpi: SLRtape50 (¼" (Quarter inch) DualReel, 25GB native, 457.2m length, 1.8MiB/s) ## Exabyte VXA-2 ## camcontrol inq $TAPE -v pass9: Removable Sequential Access SCSI-2 device pass9: Serial Number 0085105377 pass9: 80.000MB/s transfers (40.000MHz, offset 32, 16bit), Command Queueing Enabled Density 0x81 = ??? (no info about areal density found, nor bpi/ftpi) VXA-2 Drive + V10 Tape VXA V10 (8mm DualReel, 20GB native, 120m length, 5.6MiB/s) mt status -v Drive: sa4: Serial Number: 0085105377 - Mode Density Blocksize bpi Compression Current: 0x81:UNKNOWN variable 0 enabled (0x3) - Current Driver State: at rest. - Partition: 0 Calc File Numb
Re: sa(4) driver changes available for test
Bezüglich Kenneth D. Merry's Nachricht vom 19.02.2015 01:13 (localtime): > I have updated the patches. > > I have removed the XPT_DEV_ADVINFO changes from the patches to head, since > I committed those separately. > > I have (hopefully) fixed the build for the stable/10 patches by MFCing > dependencies. (One of them mav did for me, thanks!) > > Rough draft commit message: > > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt > > The patches against FreeBSD/head as of SVN revision 278975: > > http://people.freebsd.org/~ken/sa_changes.20150218.1.txt > > And (untested) patches against FreeBSD stable/10 as of SVN revision 278974: > > http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt Hello, on 26/02/2105, r278964 seems to be part from the sa_changes patchset. Do you have a sa_changes.stable_10.20150226 ready? Or is it just a matter of exluding all parts, comitted with r278964 from the patchset? I've done so in the mean while: ftp://ftp.omnilan.de/pub/FreeBSD/OmniLAN/misc/sa_changes.stable_10.20150226.fudge.patch Noticed that in sys/dev/mps/mps_sas.c 'cdai.flags' gets conditionally (#if __FreeBSD_version >= 1100061) the new "CDAI_FLAG_NONE", while in sbin/camcontrol/camcontrol.c, this is unconditionally used. Haven't really looked at the code, mostly because my skills wouldN#t allow me to answer this qusteion myself, but is that versioncheck in mps_sas.c still vaild with the rest of the sa_driver-changes? Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: sa(4) driver changes available for test
Bezüglich Kenneth D. Merry's Nachricht vom 26.02.2015 23:42 (localtime): … >>> And (untested) patches against FreeBSD stable/10 as of SVN revision 278974: >>> >>> http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt … > I'm glad it is working well for you! You can do larger I/O sizes with the > Adaptec by changing your MAXPHYS and DFLTPHYS values in your kernel config > file. e.g.: > > options MAXPHYS=(1024*1024) > options DFLTPHYS=(1024*1024) > > If you set those values larger, you won't be able to do more than 132K with > the sym(4) driver on an x86 box. (It limits the maximum I/O size to 33 > segments * PAGE_SIZE.) Thanks for the hint! I wasn't aware that kern.cam.sa.N.maxio has driver limitations corresponding to systems MAX/DFLTPHYS. I thought only silicon limitations define it's value. But in order to have a best matching pre-production test-environment, I nevertheless replaced it, now using mpt(4) instead of ahc(4)/ahc_pci on PCI-X@S3210 (for parallel tape drives I consistently have mpt(4)@PCIe, which is the same LSI(53c1020) chip but with on-board PCI-X<->PCIe bridge). Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2, LTO3 and DDS5) With DDS5, densitiy is reported as "unknown". If I remember correctly, you have your DDS4 reporting "DDS4"? > > therefore I'd like to point to the new port misc/vdmfec https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950 > That looks cool. :) I'm not a ports committer, but hopefully one of them > will pick it up. Cool it is indeed, but whether it's really usefull or not is beyond my expertise. I couldn't collect much MT experience yet. I know that LTO and similar "modern" MT technology do their own ECC (in the meaning of erasure code, mostly Reed-Solomon). What I don't know (but wanting to be best prepared for) is how arbitrary LTO drives behave, if the one (1) in 10^17 bits was detected to be uncorrectable. If it wasn't detected, the post erasure code (vdmfec in that case) would help for sure. But If the drive just cuts the output, or stops streaming at all, vdmfec was useless… According to excerpts of "Study of Perpendicular AME Media in a Linear Tape Drive", LTO-4 has a soft read error rate of 1 in 10^6 bits and DDS has 1 in 10^4 bits (!!!, according to HP C1537A DDS 3 - ACT/Apricot). So with DDS, _every_ single block pax(1) writes to tape needs to be internally corrected! Of course, nobody wants zfs' send output stream to DDS, it's much too slow/small, but just to mention. For archives of zfs streams, I don't feel safe relying on the tape drives' FEC, which was designed for backup solutions which do their own blocking+cheksumming, so the very seldom to expect uncorrectable read error would at worst lead to some/single unrecoverable files – even in case of database files most likely post-recoverable. But with one flipped bit in the zfs stream, you'd loose hundred of gigabytes, completely unrecoverable! As long as the tape keeps spitting complete blocks, even in the case when the tape knows that the output is not correct, vdmfec ought to be the holy grail :-) Going slightly more off topic: One hot candidate for beeing another holy grail, is mbuffer(1) for me. I don't know if tar/pax/cpio do any kind of FIFO buffering at all, but for zfs-send-streaming, mbuffer(1) is obligatory. Even with really huge block sizes, you can't saturate LTO-3 native rate. With mbuffer(1) it's no problem to stream LTO-4 native rate with a tape-transport-blocksize of 32k. Btw, besides the FIFO-buffering, I'm missing star(1) also for it's multi-volume support. tar(1) in base isn't really useful for tape buddies – IMHO it's hardly adequate for any purpose and I don't understand it's widespread usage… Most likely the absence of dump(8) for zfs misleads to tar(1) ;-) Were there ever thoughts about implementing FIFO-buffering into sa(4)? We don't have mbuffer(1) in base, but I think, to complete FreeBSD's tape support, users should find all technology/tools, needed for using modern tape drives, in base. If sa(4) could provide sysctl-controlled FIFO-buffering, some base tools were a bit more apropriate for tape usage, I think. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: sa(4) driver changes available for test
Bezüglich Kenneth D. Merry's Nachricht vom 19.02.2015 01:13 (localtime): > I have updated the patches. > > I have removed the XPT_DEV_ADVINFO changes from the patches to head, since > I committed those separately. > > I have (hopefully) fixed the build for the stable/10 patches by MFCing > dependencies. (One of them mav did for me, thanks!) > > Rough draft commit message: > > http://people.freebsd.org/~ken/sa_changes_commitmsg.20150218.1.txt > > The patches against FreeBSD/head as of SVN revision 278975: > > http://people.freebsd.org/~ken/sa_changes.20150218.1.txt > > And (untested) patches against FreeBSD stable/10 as of SVN revision 278974: > > http://people.freebsd.org/~ken/sa_changes.stable_10.20150218.1.txt Ken, thank you very much for your work! Last sa(4) overhaul (with 10.0 I guess) was a great success and I highly appreciate your work on tape support for FreeBSD! I compiled your 10-stable patchset for one machine with LTO2 and DDS5 drives, but haven't done much testing since I'll replace the adaptec (39160) because it's maxio is limited to 64k (while 53c1020 has 128k). sa(4) seems to work just fine with both drives, mt(1) showing "Reported File/Record Number" :-) No EOM tests done so far… I'll archive zfs streams, therefore I needed some kind of forward error correction. Probably people following this thread also have found to need this, therefore I'd like to point to the new port misc/vdmfec https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197950 Perhaps someone want's to take this bug report. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: Changing makeoptions UKBD_DFLT_KEYMAP leads to kernel build fail
Bezüglich Oliver Pinter's Nachricht vom 16.11.2014 12:53 (localtime): > On 11/15/14, Dominik Zajac wrote: >> Hi, >> >> I am trying to change the default keymap for my keyboard therefore I >> added the following options to my kernel configuration which leads to >> the error bellow. >> >> Added options: >> >> options KBD_INSTALL_CDEV >> >> options UKBD_DFLT_KEYMAP >> >> makeoptions UKBD_DFLT_KEYMAP=de.iso >> >> >> I tried it with this, too: >> >> makeoptions UKBD_DFLT_KEYMAP=german.iso >> >> >> Both leads to the following problem: >> >> >> /usr/src/sys/dev/usb/input/ukbd.c:1209:18: error: use of undeclared >> identifier 'key_map' >> >> sc->sc_keymap = key_map; >> >> ^ >> >> /usr/src/sys/dev/usb/input/ukbd.c:1210:18: error: use of undeclared >> identifier 'accent_map' >> >> sc->sc_accmap = accent_map; >> >> ^ >> >> 2 errors generated. >> >> *** Error code 1 > Hi! > > See this ticket: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194744 and the > related bugs. > >> Is there a dynamic way to change the keyboard layout at boot time to typ >> the zfs passphrase on my default keyboardlayout? No, you need to change default keymap, like you already found how to. But even if you use the keymap-name matching your current console (unlucky dependency at least since vt and sc use different keymap names, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865, already listed as related in Oliver Pinter's BugReport), it most likely won't work for you, since you actually use kbdmux(4) instead ukbd(4) (if you haven't changed in your kernel conf). So first you have to make kbdmux's default keymap customizable (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=153459), then you'll probably want to get rid of the build-dependency of matching keymap-names to the build-machine's active console (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193865). The latter especially for kbdmux, wich is an extra patch you can find in the first BugReport. It's working fine here in some dozend setups, also had feedback that it works, but found none having time to give it a short review and commit it. Wondering why you get "error: use of undeclared identifier 'accent_map'"; If our active console is vt(4) and you define "de" or "de.kbd" [found while writing, you named de.iso!]… -Harry signature.asc Description: OpenPGP digital signature
Re: missing nullmailer feature in dma(8)/dmagent
Bezüglich Baptiste Daroussin's Nachricht vom 03.11.2014 13:20 (localtime):
> On Mon, Nov 03, 2014 at 12:52:04PM +0100, Harald Schmalzbauer wrote:
>> Bezüglich Harald Schmalzbauer's Nachricht vom 28.10.2014 17:54
>> (localtime):
>>> Bezüglich Baptiste Daroussin's Nachricht vom 28.10.2014 17:44 (localtime):
>>> …
>>>> The NULLCLIENT feature should exactly be what you are looking for, no?
>>>> As written in the manpage:
>>>>
>>>>
>>>> Bypass aliases and local delivery, and instead forward all mails to
>>>> the defined `SMARTHOST'. `NULLCLIENT' requires `SMARTHOST' to be
>>>> set.
>>>>
>>> Doh… should try harder getting more sleep ;-)
>>> Sorry for the noise, seems indeed to be exactly what I was looking for.
>>> Can't explain why I missed that, thanks!
>> Ahh, now I can explain ;-)
>> It's the port's version (v0.9_1,1) which lacks this feature.
>> I saw on github that you added this functionality in February 2014, but
>> VERSION wasn't bumped since June 2013.
>> So I guess the port does checkout an outdated version?
>>
>> Thanks,
>>
>> -Harry
>>
> That is it, but I lack motivation to work on it. If one want to take
> maintainership on it and update it, please help yourself
Fair enough. Unfortunately both, time and skills are limited; sufficient
to help myself, though.
For anyone intersted, attached is a diff which does a quick'n'dirty
dma-devel (copy mail/dma to inofficial/dma-devel and apply the patch).
Packaging works, can't tell anything about the condition of the GitHub
code from Sep, 8th 2014 (commit
b1056e4384472dbbedd6b075819abd6154ac0d69) but I don't expect regressions
so will use it and would report if I found problems.
Thanks,
-Harry
diff -ur mail/dma/Makefile inofficial/dma-devel/Makefile
--- mail/dma/Makefile 2014-11-03 14:24:47.430297295 +0100
+++ inofficial/dma-devel/Makefile 2014-11-03 15:12:43.791680603 +0100
@@ -1,22 +1,26 @@
# Created by: Daniel Roethlisberger
# $FreeBSD: head/mail/dma/Makefile 367307 2014-09-04 19:26:24Z antoine $
-PORTNAME= dma
-PORTVERSION= v0.9
-PORTREVISION= 1
-PORTEPOCH= 1
+PORTNAME= dma-devel
+PORTVERSION= v0.10
+#PORTREVISION= 1
+#PORTEPOCH= 1
CATEGORIES= mail ipv6
EXTRACT_SUFX=
+CONFLICTS_INSTALL= dma-*
MAINTAINER= b...@freebsd.org
COMMENT= DragonFly Mail Agent, a small MTA for local/outbound mail
+VALID_CATEGORIES+= inofficial
+
LICENSE= BSD3CLAUSE
USE_OPENSSL= yes
USE_GITHUB= yes
-GH_COMMIT= 2bb8bcb
+GH_PROJECT= dma
+GH_COMMIT= b1056e4
GH_ACCOUNT= corecode
GH_TAGNAME= ${GH_COMMIT}
diff -ur mail/dma/distinfo inofficial/dma-devel/distinfo
--- mail/dma/distinfo 2014-11-03 14:24:47.450316423 +0100
+++ inofficial/dma-devel/distinfo 2014-11-03 14:59:00.438986799 +0100
@@ -1,2 +1,2 @@
-SHA256 (dma-v0.9) = 6c99d5975a2a1072f74b3209ad0a2b89558274de39bd3e03400f94a242b436f2
-SIZE (dma-v0.9) = 45611
+SHA256 (dma-devel-v0.10) = 05348aa91e838d819627a31db82afbdb4edba5fa4a81e90992616e031761eea2
+SIZE (dma-devel-v0.10) = 33985
signature.asc
Description: OpenPGP digital signature
Re: missing nullmailer feature in dma(8)/dmagent
Bezüglich Harald Schmalzbauer's Nachricht vom 28.10.2014 17:54 (localtime): > Bezüglich Baptiste Daroussin's Nachricht vom 28.10.2014 17:44 (localtime): > … >> The NULLCLIENT feature should exactly be what you are looking for, no? >> As written in the manpage: >> >> >> Bypass aliases and local delivery, and instead forward all mails to >> the defined `SMARTHOST'. `NULLCLIENT' requires `SMARTHOST' to be >> set. >> > Doh… should try harder getting more sleep ;-) > Sorry for the noise, seems indeed to be exactly what I was looking for. > Can't explain why I missed that, thanks! Ahh, now I can explain ;-) It's the port's version (v0.9_1,1) which lacks this feature. I saw on github that you added this functionality in February 2014, but VERSION wasn't bumped since June 2013. So I guess the port does checkout an outdated version? Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: missing nullmailer feature in dma(8)/dmagent
Bezüglich Baptiste Daroussin's Nachricht vom 28.10.2014 17:44 (localtime): … > The NULLCLIENT feature should exactly be what you are looking for, no? > As written in the manpage: > > > Bypass aliases and local delivery, and instead forward all mails to > the defined `SMARTHOST'. `NULLCLIENT' requires `SMARTHOST' to be > set. > Doh… should try harder getting more sleep ;-) Sorry for the noise, seems indeed to be exactly what I was looking for. Can't explain why I missed that, thanks! -Harry signature.asc Description: OpenPGP digital signature
missing nullmailer feature in dma(8)/dmagent
Hello, I haven't found a way to instruct dma(8) to also forward unqualified recipients to the relayhost. It always delivers unqualified addresses locally (if not translated by "aliases"). ssmtp(8) provides an option to define a recipient address for all local recipients who's ID is <1000. nullmailer(7) does exactly what I want, it doesn't care about the host part of the recipient address, it just passes it over. I'm missing an option for dma(8), which disables local delivery completely, or like ssmtp, optionally only for ids <1000 resp. not existing local users. Why?: Maintaining aliases at each machine is too expensive. My aim is that any operator or daemon of any (human-users-less) machine can simply drop mails to 'chief' or 'root' or 'monitor'. Then there are MSAs (I don't call them mailhub, in my world a mailhub stores email, which often is called a "mailhost"), and only these MSAs care about recipient aliasing and delivery to mailhub or relayhost. With that setup I have exactly one (resp. each redundant MSA) place to maintain aliases and/or other forwarding rules/mailertables etc. Since most smtp-agent implementations handle multiple A records – although I haven't found one which evaluates MX records – and I have more than one MSA, I can pretty reliably guaranteee that any failing machine/device/daemon can drop a note which won't get lost. If I did aliasing on the mailhub instead at the interposed MSA, I'd loose poor mans' redundancy… According to dma(8) on 11-current, it's the same like in ports (mail/dma), which I used for testing. I like the decision to replace sendmail, since almost any time in the past when I really needed to use the fullfeatured MTA capabilities, I had to replace base sendmail with a SASL extended version… But I'd still need to spread nullmailer(7) with current's dma featrues in 11. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: CURRENT: EFI boot failure
Bezüglich O. Hartmann's Nachricht vom 04.10.2014 08:47 (localtime):
…
>> 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
>>
> Has this problem anyhow seriously been addressed? I run into this very often
> on several
> platforms with HAswell-based CPUs (other systems with IvyBridge or
> SandyBridge are still
> to be migrated to UEFI boot, so I do not have any older architectures at hand
> to proof
> whether this issue is still present or not on Non-AVX2 systems.
>
> If there is no progress so far, would it be well-advised to open a PR?
Unofrtunately I don't really have qualified knwoledge about compiler
optimazations nor any efi binary knwoledge.
Opening a PR is really needed, this issue shouldn't be left unchecked.
But I'd prefer if someone does it, who understands what Matt Fleming
answered in
http://lists.freebsd.org/pipermail/freebsd-current/2014-September/052354.html
Anyone?
Thanks,
-Harry
signature.asc
Description: OpenPGP digital signature
Re: installincludes, bsd.incs.mk and param.h
Bezüglich Ian Lepore's Nachricht vom 14.10.2014 19:00 (localtime): … > The old code that used to work for you got the version via sysctl, so I > was recommending that you keep doing that yourself, since it's no longer > built in to bsd.ports.mk. > > So just add "export OSVERSION=`sysctl kern.osreldate` to your script > that kicks off this update process, something like that. Thank you for your support! Like for many others, the former OSVERSION detection wasn't working very well for me with jail environments (python broke e.g.). Therefore I had worked arround it defferently, nonetheless I'm not happy with reverting to the old behaviour. Since /usr/include gets populated regardless if "WITHOUT_TOOLCHAIN=true" was set in src.conf, I think it's a good idea to have the one param.h also installed, regardless of the option. Please see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194401 Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: installincludes, bsd.incs.mk and param.h
Bezüglich Ian Lepore's Nachricht vom 14.10.2014 17:37 (localtime): ... > It appears that while bsd.ports.mk has lost the ability to use the > version of the running system (sysctl kern.osreldate), it still has the > logic to just use OSVERSION if it's already set on the make command line > or in the environment. Can you leverage that to regain the behavior > you're used to? In general yes, that's what I did since my last ports-svn-update, but only to avoid complete breakage. Problem is that I have absolutely not in mind what OSVERSION on what machine to set. So I'm supplying a "dummy" version. That shouldn't be a problem for my purposes, but it's simply wrong. This check was introduced to gather the »correct« OSVERSION ;-) And manually supplying the correct version doesn't work due to brain contraints ;-) I like the idea to ask a userland installed indicator. But I'm not familar enough with bsd.incs.mk and the related installworld stage. I'd just need the hint from where include/Makefile gets conditionally (MK_TOOLCCHAIN!=no) included ... ?!? Somwhere it start's recursing the SUBDIRs, and I guess every binary calls installincludes: from it's directory (which works since bsd.lib.mk and bsd.prog.mk include bsd.incs.mk), but I can't find at what SUBDIR param.h is involved. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: installincludes, bsd.incs.mk and param.h
Bezüglich David Wolfskill's Nachricht vom 14.10.2014 16:52 (localtime): > On Tue, Oct 14, 2014 at 04:42:57PM +0200, Harald Schmalzbauer wrote: >> Hello, >> >> since bsd.port.mk insinsts on param.h, I have inconveniences on my >> production systems which were installed with "WITHOUT_TOOLCHAIN=true" in >> src.conf (resulting in MK_TOOLCHAIN=no). >> >> My first attempt was the following patch: >> ... >> "$SYSDIR" makes the example above not working! >> Unfortunately I couldn't figure out when/how param.h gets installed. >> Also, I couldn't find out what stage uses include/Makefile, only that >> it's not used when MK_TOOLCHAIN=no. >> >> Any help highly appreciated! >> > My production systems have their OS built on a "build machine"; at > install time, the build machine exports its /usr/src and /usr/obj, and I > "make installkernel installworld" (& mergemaster...) on the production > systems. > > I'm still building ports using portmaster on the production systems (as > I lack the infrastructure to create my own pkg repository, and I need > some non-default options), so I export the build machine's /usr/src & > /usr/obj to the production machines during the ports builds, as well. > > That said, I don't try to do anything with respect to MK_TOOLCHAIN -- in > normal use, the production machines don't have /usr/src or /usr/obj at > all anyway. > > In any case, this has generally been working for me for many years. Sounds reasonable. For one (big) enivronment at least. I have different, completely unrelated environments which I maintain. Therefore I do have a complete project-oriented build- and rollout infrastruture, which also handles ports/packages (most times distributed as repository on CD, each CD a set of applications for one distinct machine). So on my production systems, I don't need to (and even can't) compile any sources, but on some of them, I often use the ports tree for update checks or various - destination machine unrelated - tasks, like 'make fetch' for having a convenient way looking into sources e.g. ... The ports tree has been a very valuable source for me in many aspects, not just for compiling anything. The param.h dependent OSVERSION check is relatively new, but bites me frequently. So I really need a possibility to make the ports tree usable again on machines which don't have any part of TOOLCHAIN installed. Preferably I'd like to "fix" the dependency as close as possible to the FreeBSD standard build environment, instead of botching post-installworld... Thanks, -Harry signature.asc Description: OpenPGP digital signature
installincludes, bsd.incs.mk and param.h
Hello,
since bsd.port.mk insinsts on param.h, I have inconveniences on my
production systems which were installed with "WITHOUT_TOOLCHAIN=true" in
src.conf (resulting in MK_TOOLCHAIN=no).
My first attempt was the following patch:
--- share/mk/bsd.incs.mk.orig 2014-10-14 16:35:53.0 +0200
+++ share/mk/bsd.incs.mk2014-10-14 16:34:57.0 +0200
@@ -81,4 +81,9 @@
realinstall: installincludes
.ORDER: beforeinstall installincludes
+.else
+installincludes:
+${INSTALL} -C -o ${BINOWN} -g ${BINGRP} -m ${NOBINMODE} \
+${SYSDIR}/sys/param.h ${DESTDIR}${INCLUDEDIR}/sys/sys
+
.endif # !defined(NO_INCS) && ${MK_TOOLCHAIN} != "no"
"$SYSDIR" makes the example above not working!
Unfortunately I couldn't figure out when/how param.h gets installed.
Also, I couldn't find out what stage uses include/Makefile, only that
it's not used when MK_TOOLCHAIN=no.
Any help highly appreciated!
Thanks,
-Harry
signature.asc
Description: OpenPGP digital signature
Re: installworld broken - osreldate.h: permission denied
Bezüglich Ian Lepore's Nachricht vom 28.09.2013 19:19 (localtime):
> On Sat, 2013-09-28 at 15:09 +0200, Joel Dahl wrote:
>> Hi,
>>
>> Fresh HEAD. installworld from read-only /usr/obj and /usr/src:
>>
>> /usr/src/include/iconv.h osreldate.h /usr/include
>> install: osreldate.h: Permission denied
>> *** Error code 71
>>
>> Stop.
>> make[4]: stopped in /usr/src/include
>> *** Error code 1
>>
>> Everything was working fine 2 weeks ago, so it's a recent breakage.
>>
> Okay, I just accidentally created conditions for this error on my
> system... I checked in a change to newvers.sh while a buildworld was
> running, which led to a situation where newvers.sh was newer than
> osreldate.h at the end of the buildworld. Then an installworld tried to
> regenerate osreldate.h due to its dependency on newvers.sh, which would
> fail if the obj was readonly at that point.
>
> I think we could see if something similar applies for you if you use
> this command:
>
> make -dm installworld SUBDIR_OVERRIDE=include
>
> And we'd be looking for the end of the output to be something like:
>
> Examining _libiconv_compat.h...
> modified 10:51:18 Sep 28, 2013...up-to-date
> Make_Update: _libiconv_compat.h
> inspect parent buildincludes: flags 0, type 18001, made 0, unmade 95 - not
> needed
> inspect parent _INCSINS: flags 9, type b01, made 1, unmade 1 - unmade
> children
> Examining osreldate.h...
> modified 10:39:21 Sep 28, 2013...modified before source
> /local/build/staging/freebsd/head/src/include/../sys/conf/newvers.sh...out-of-date
> env ECHO="echo"
> MAKE="/local/build/staging/freebsd/head/obj/local/build/staging/freebsd/head/src/make.i386/bmake"
>
> NEWVERS_SH=/local/build/staging/freebsd/head/src/include/../sys/conf/newvers.sh
> PARAM_H=/local/build/staging/freebsd/head/src/include/../sys/sys/param.h
> SYSDIR=/local/build/staging/freebsd/head/src/include/../sys sh
> /local/build/staging/freebsd/head/src/include/mk-osreldate.sh
> env: not found
> *** [osreldate.h] Error code 127
>
> The "env: not found" is what I got instead of a permission denied, and
> probably has something to do with me cross-building amd64 10.0 from an
> i386 8.x machine. I think that's where you'd see the permission error.
>
> If the same sort of thing is happening for you, then all that's left is
> to figure out why osreldate.h is out of date at install time, and how to
> handle things if that's the case.
Thanks for your suggestion how to best find out what's going on.
I have the same problem you observed (env: not found), not the
permission problem the thread opener had.
For any reason, not relevant at this point, my
${src}/sys/conf/newvers.sh is newer than 'include/osreldate.h' under
$OBJDIRPREFIX/i386.i386/….
Now in 'include/Makefile', "sh ${MK_OSRELDATE_SH}" should be called by
'env' in target 'osreldate.h vers.c:'.
Problem is, that PATH has sevaral bin-sbin directories under
"$OBJDIRPREFIX/…/tmp/" _and_ "$INSTALLTMP", and none of them provides 'env'.
The latter is filled with target 'distributeworld installworld:' in
Makefile.inc1, with $ITOOLS.
The following additional tools are missing in ITOOLS
to make recreating osreldate.h work at installworld stage:
env, hostname, mktemp and touch
So a patch to work arround that issue looks like this:
--- src/Makefile.inc1.orig 2014-09-25 17:36:16.0 +0200
+++ src/Makefile.inc1 2014-09-25 17:47:14.0 +0200
@@ -697,9 +697,9 @@
.endif
ITOOLS= [ awk cap_mkdb cat chflags chmod chown \
- date echo egrep find grep id install ${_install-info} \
- ln lockf make mkdir mtree ${_nmtree_itools} mv pwd_mkdb \
- rm sed sh sysctl test true uname wc ${_zoneinfo}
+ date echo egrep env find grep hostname id install ${_install-info} \
+ ln lockf make mkdir mktemp mtree ${_nmtree_itools} mv pwd_mkdb \
+ rm sed sh sysctl test touch true uname wc ${_zoneinfo}
#
# distributeworld
I have no idea if there's a better way, but if these tools are not to be
added, the check for outdated osreldate.h should be disabled because
recreation at install stage is not possible without. At least this is
true for compiling 9.3-i386 on 10-stable-amd64.
-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: /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 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: CURRENT: EFI boot failure
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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
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
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: nscd not caching
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" 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
zfs ARC behaviour, Bug 187594
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: r268621: panic: shadowed tmpfs v_object [with dump]
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 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
Re: Feature request: sticky bit inheritance
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
Re: Feature request: sticky bit inheritance
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
Feature request: sticky bit inheritance
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: New iSCSI stack.
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
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
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.cm
Re: [CFT] VMware vmxnet3 ethernet driver
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
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 >> wrote: >>>> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao >> wrote: >>>>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao >> wrote: >>>>>> 2012/7/4 Attilio Rao : >>>>>>> 2012/6/29 Attilio Rao : >>>>>>>> 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
Bezüglich Attilio Rao's Nachricht vom 14.10.2012 02:27 (localtime): > On Fri, Sep 21, 2012 at 1:22 AM, Attilio Rao wrote: >> On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao wrote: >>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao wrote: 2012/7/4 Attilio Rao : > 2012/6/29 Attilio Rao : >> 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
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
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=808843 > metric 0 mtu 1500 fib 15 > options=3 > 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=21 > media: Ethernet autoselect (1000baseT ) > 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
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=0x1fa3fbff Features2=0xfeba2203 AMD Features=0x28100800 AMD Features2=0x1 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: 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 cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf6b80 00024 (v02 PTLTD ) ACPI: XSDT 0xb
Re: Bull Mountain (IvyBridge +) random number generator
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=0x1fa3fbff Features2=0xfeba2203 AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8235110400 (7853 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: 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
schrieb Attilio Rao am 28.09.2012 16:18 (localtime): > On Wed, Sep 26, 2012 at 12:02 PM, Harald Schmalzbauer > 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
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 wrote: >>> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao wrote: >>>> 2012/7/4 Attilio Rao : >>>>> 2012/6/29 Attilio Rao : >>>>>> 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 l
Re: MPSAFE VFS -- List of upcoming actions
schrieb Attilio Rao am 21.09.2012 02:22 (localtime): > On Wed, Sep 19, 2012 at 3:48 AM, Attilio Rao wrote: >> On Fri, Jul 13, 2012 at 12:18 AM, Attilio Rao wrote: >>> 2012/7/4 Attilio Rao : 2012/6/29 Attilio Rao : > 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
Idea for GEOM and policy based file encryption
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
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
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/
Re: beta2 panic: VAPPEND without VWRITE
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
beta2 panic: VAPPEND without VWRITE
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
OT [was: Re: HEADS UP: /bin and /sbin are now dynamically linked]
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: please test pcm patch
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: port 0xef00-0xef3f,0xe800-0xe8ff irq 17 at device 31.5 on pci0 pcm0: 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: Nvidia problem fixed in current?
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: i have linux mandrake
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
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: 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=0x383fbff real memory = 268173312 (255 MB) avail memory = 250781696 (239 MB) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc07760c2 (122) VESA: NVIDIA acpi0: 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: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci2: on pcib1 pcib1: slot 0 INTA is routed to irq 16 nvidia0: mem 0xf000-0xf3ff,0xfd00-0xfdff irq 16 at device 0.0 on pci2 pcib2: at device 30.0 on pci0 pci1: on pcib2 fxp0: port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: 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: port 0xef40-0xef5f irq 19 at device 31.2 on pci0 usb0: 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: port 0xefa0-0xefaf irq 17 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 uhci1: port 0xef80-0xef9f irq 23 at device 31.4 on pci0 usb1: 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: port 0xef00-0xef3f,0xe800-0xe8ff irq 17 at device 31.5 on pci0 pcm0: atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 fdc0: 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: on motherboard npx0: INT 16 interface orm0: at iomem 0xd0800-0xd17ff,0xcf800-0xd07ff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <12 virtual consoles, flags=0x300> vga0: 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 [79408/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-master PIO4 pcm0: measured ac97 link rate at 55942 Hz Mounting root from ufs:/dev/ad0s2a module_register: module uhub/ums already exists! Module uhub/ums failed to register: 17 Warning: pid 578 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 584 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 585 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 605 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 606 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 607 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 608 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 611 used static ldt allocation. Se
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
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,
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
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)
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++;
> }
> }
>
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
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: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 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
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: 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
General debug/kernel question
Salve, I always thought that building a kernel with debug symbols would increase the kernel size dramatically. But if I understand things right the additioal "symbols" (code snippets?) are not in the kernel but in a different file which makes the kernel the same size like without debug=-g. Is there any reason to not build it with debug=-g? Also I thought debug kernels suffer from reduced performance. I also have DDB in my kernel and don't _feel_ any difference. So again, is there any reason not to put DDB into the kernel? Thanks, -Harry pgp0.pgp Description: signature
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: 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: 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: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
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 Serve
Re: ULE and very bad responsiveness
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: ULE and very bad responsiveness
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: 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=0x383fbff real memory = 268173312 (255 MB) avail memory = 250781696 (239 MB) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc0760fe2 (122) VESA: NVIDIA acpi0: 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: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci2: on pcib1 pcib1: slot 0 INTA is routed to irq 16 nvidia0: mem 0xf000-0xf3ff,0xfd00-0xfdff irq 16 at device 0.0 on pci2 pcib2: at device 30.0 on pci0 pci1: on pcib2 fxp0: port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: 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: port 0xef40-0xef5f irq 19 at device 31.2 on pci0 usb0: 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: port 0xefa0-0xefaf irq 17 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 uhci1: port 0xef80-0xef9f irq 23 at device 31.4 on pci0 usb1: 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: port 0xef00-0xef3f,0xe800-0xe8ff irq 17 at device 31.5 on pci0 pcm0: atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 fdc0: 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: on motherboard npx0: INT 16 interface orm0: at iomem 0xd0800-0xd17ff,0xcf800-0xd07ff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <12 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 1095826590 Hz quality 800 Timecounters tick every 1.000 msec GEOM: create disk ad0 dp=0xc2d99760 ad0: 39083MB [79408/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-master PIO4 pcm0: measured ac97 link rate at 55931 Hz Mounting root from ufs:/dev/ad0s2a Warning: pid 574 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 580 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 581 used static ldt allocation. See the i386_set_ldt man page for more in
ULE and very bad responsiveness
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 --- Begin Message --- 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: which 3ware controllers are supported ?
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
Re: APIC-UP related panic
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: 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=0x383fbff real memory = 268173312 (255 MB) avail memory = 250781696 (239 MB) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc07603e2 (122) VESA: NVIDIA acpi0: 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: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci2: on pcib1 pcib1: slot 0 INTA is routed to irq 16 nvidia0: mem 0xf000-0xf3ff,0xfd00-0xfdff irq 16 at device 0.0 on pci2 pcib2: at device 30.0 on pci0 pci1: on pcib2 fxp0: port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: 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: port 0xef40-0xef5f irq 19 at device 31.2 on pci0 usb0: 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:
Re: APIC-UP related panic
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
Re: APIC-UP related panic
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
APIC-UP related panic
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: 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=0x383fbff real memory = 268173312 (255 MB) avail memory = 250781696 (239 MB) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc07600e2 (122) VESA: NVIDIA acpi0: 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: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci2: on pcib1 pcib1: slot 0 INTA is routed to irq 16 nvidia0: mem 0xf000-0xf3ff,0xfd00-0xfdff irq 16 at device 0.0 on pci2 pcib2: at device 30.0 on pci0 pci1: on pcib2 fxp0: port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: 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: port 0xef40-0xef5f irq 19 at device 31.2 on pci0 usb0: 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: port 0xefa0-0xefaf irq 17 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 uhci1: port 0xef80-0xef9f irq 23 at device 31.4 on pci0 usb1: 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: port 0xef00-0xef3f,0xe800-0xe8ff irq 17 at device 31.5 on pci0 pcm0: atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 fdc0: 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: on motherboard npx0: INT 16 interface orm0: at iomem 0xd0800-0xd17ff,0xcf800-0xd07ff on isa0 pmtimer0 on isa0 sc0: at flags 0x1
panic with today's -current
Sorry, all I have are these lines from messages. I returned and saw that the machine had rebooted. Nothing more: Nov 5 02:46:42 cale syslogd: kernel boot file is /boot/kernel/kernel Nov 5 02:46:42 cale kernel: instruction pointer= 0x8:0xc054c85d Nov 5 02:46:42 cale kernel: stack pointer = 0x10:0xcdc9dbe0 Nov 5 02:46:42 cale kernel: frame pointer = 0x10:0xcdc9dbe4 Nov 5 02:46:42 cale kernel: code segment = base 0x0, limit 0xf, type 0x1b Nov 5 02:46:42 cale kernel: = DPL 0, pres 1, def32 1, gran 1 Nov 5 02:46:42 cale kernel: processor eflags = interrupt enabled, IOPL = 0 Nov 5 02:46:42 cale kernel: current process= 26 (irq16: nvidia0) Nov 5 02:46:42 cale kernel: trap number= 30 Nov 5 02:46:42 cale kernel: panic: unknown/reserved trap Nov 5 02:46:42 cale kernel: Nov 5 02:46:42 cale kernel: syncing disks, buffers remaining... 2202 2202 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 2199 Nov 5 02:46:42 cale kernel: giving up on 1066 buffers Nov 5 02:46:42 cale kernel: Uptime: 3h15m57s Nov 5 02:46:42 cale kernel: Shutting down ACPI Nov 5 02:46:42 cale kernel: stray irq9 Nov 5 02:46:42 cale kernel: Automatic reboot in 15 seconds - press a key on the console to abort Nov 5 02:46:42 cale kernel: Rebooting... 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 [79408/16/63] at ata0-master UDMA100 > > acd0: CDROM 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
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 [79408/16/63] at ata0-master UDMA100 acd0: CDROM 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: 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 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
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 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 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: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: 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=0x383fbff 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: on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f2a10 pcib0: at pcibus 0 on motherboard pci0: 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: at device 1.0 on pci0 pci2: on pcib1 pci_cfgintr: 0:1 INTA routed to irq 4 pcib1: slot 0 INTA is routed to irq 4 nvidia0: mem 0xf000-0xf3ff,0xfd00-0xfdff irq 4 at device 0.0 on pci2 pcib2: at device 30.0 on pci0 pci1: on pcib2 pci_cfgintr: 1:8 INTA BIOS irq 11 fxp0: port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 11 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: 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: port 0xef40-0xef5f irq 7 at device 31.2 on pci0 usb0: 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: port 0xefa0-0xefaf irq 9 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 uhci1: port 0xef80-0xef9f irq 10 at device 31.4 on pci0 usb1: 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: port 0xef00-0xef3f,0xe800-0xe8ff irq 9 at device 31.5 on pci0 pcm0: orm0: at iomem 0xd0800-0xd17ff,0xcf800-0xd07ff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 fdc0: 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 sc0: at flags 0x100 on isa0 sc0: VGA <12 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 1095821276 Hz quality 800
New 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: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: 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: floppies
On Monday 03 November 2003 09:50, Dag-Erling Smørgrav wrote: > anyone else having trouble with floppies? I tried a bunch of > different disks in two different machines (5.1-CURRENT with brand new > drive, 4.9-PRERELEASE with an older but presumed-good drive) and all I > get are I/O errors; fdformat sometimes works and sometimes doesn't, > and any attempt to actually read or write data fails. I can confirm that. See this attached posting from 13. October 2003 -Harry > > # uname -a > FreeBSD ada.des.no 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #5: Fri Sep 5 > 22:56:22 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/compile/ada i386 # > fdformat fd0 > Format 1440K floppy `/dev/fd0'? (y/n): y > Processing fdformat: ioctl(FD_FORM): Input/output error > # dd if=/dev/zero of=/dev/fd0c > dd: /dev/fd0c: Input/output error > 1+0 records in > 0+0 records out > 0 bytes transferred in 2.634334 secs (0 bytes/sec) > > and the console shows: > > fd0: recal failed ST0 70 cyl 0 > last message repeated 2 times > fd0: recal failed ST0 78 cyl 0 > fd0c: hard error writing fsbn 0 (No status) > > on -CURRENT: > > # fdformat fd0 > Format 1440K floppy `/dev/fd0'? (y/n): y > Processing VEVV done. > Errors encountered: > Cyl Head Sect Error > 661 12 wrong cylinder (format mismatch) > > (although a previous run succeeded) > > I'm having a hard time believing this is a hardware problem, although > there might conceivably be an environmental factor which affects both > systems since they are in the same room. > > DES --- Begin Message --- Hi all, dmesg doesn't show anything unusual but trying to mount disks known to be good results in mount: /dev/fd0: Input/output error. Also fdformat does not work. It shows me every sector bad. Btw: How can I format a floppydisk in a USB-drive? fdformat /dev/da0 doesn't work. The USB-drive is fine, also is the standard floppy drive. I'm running FreeBSD 5.1-CURRENT #20: Sun Oct 12 23:31:45 CEST 2003 Thanks, -Harry pgp0.pgp Description: signature --- End Message --- pgp1.pgp Description: signature
Re: hw.ata.atapi_dma vanished
On Monday 03 November 2003 05:42, Kent Stewart wrote: > On Sunday 02 November 2003 03:40 pm, Harald Schmalzbauer wrote: > > Hello, grumpf, > > > > after having had the first spontanous reboot with -current for a long > > time I wanted to look for hw.ata.atapi_dma (since the machine crashed > > (without ANY report) when I tried to access the CD) and found it's gone. > > The man page still tells my stories about that sysctl. > > > > What news did I miss? > > man ata You add it to /boot/loader.conf now. I always had it in loader.conf.local but why is this sysctl not listed anymore? cale:~> sysctl hw.ata hw.ata.ata_dma: 1 hw.ata.wc: 1 I can remember some other sysctl which were not displayed before altered. How can I get ALL sysctls? (-a also just shows these two hw.ata) I think some time ago hw.ata.atapi_dma was listed, no matter if it was alered before or not. Thanks, -Harry > > Kent pgp0.pgp Description: signature
hw.ata.atapi_dma vanished
Hello, grumpf, after having had the first spontanous reboot with -current for a long time I wanted to look for hw.ata.atapi_dma (since the machine crashed (without ANY report) when I tried to access the CD) and found it's gone. The man page still tells my stories about that sysctl. What news did I miss? Thank you, -Harry pgp0.pgp Description: signature
Re: CDDA with common programs (ATAng)
On Sunday 02 November 2003 17:01, Soren Schmidt wrote: > It seems Harald Schmalzbauer wrote: > > Ha, stop. Today it doesn't work as non-root anymore. > > I'm sure with -current some days ago and the same patch it worked without > > root privileges. > > I can't follow that. > > Thats a feature of atapi-cd now being under GEOM.. > > The device nodes are now mode 640 which the security mob has been > nagging me about for years. > > So now you know where to direct complaints :) Ok, found that so some entries in devfs.conf did the trick. The rest I wrote obove was wrong. Accidentaly I forgot to remove the patch in the files directory, so cdparanoia still fails to build on -current. cooked_interface.c: In function `cooked_read': cooked_interface.c:204: error: storage size of `arg' isn't known cooked_interface.c:215: error: `CDIOCREADAUDIO' undeclared (first use in this function) cooked_interface.c:215: error: (Each undeclared identifier is reported only once cooked_interface.c:215: error: for each function it appears in.) gmake[2]: *** [cooked_interface.o] Fehler 1 Thanks, -Harry > > -Søren > ___ > [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: CDDA with common programs (ATAng)
On Saturday 01 November 2003 23:06, Artem 'Zazoobr' Ignatjev wrote: > On Sat, 01.11.2003, at 11:08, Harald Schmalzbauer ÐÉÛÅÔ: *SNIP* > > There were great tools which could do that automatically but they don't > > work any more for a reason I cannot follow. > > I've ran accross this one some time ago - dagrab no longer work, neither > cdparanoia was. > After recvsup of ports/audio and recompile of dagrab all went fine. Thank you for that hint, also to Arjan van Leeuwen. First I tried Arjan's hint which worked fine. Today I built world and tried the unpatched original port which builds fine again. Seems the changes have been backed out or whatever. But it's not working for me. First I can't run it as non-root and then it seems to need atapicam which I haven't. With Arjan's link it works without atapicam and as non-root. I think this patch should be commited. Ha, stop. Today it doesn't work as non-root anymore. I'm sure with -current some days ago and the same patch it worked without root privileges. I can't follow that. Thanks a lot, -Harry pgp0.pgp Description: signature
CDDA with common programs (ATAng)
Hi all, in the archive I found a discussion about some implementation changes with ATAng which breakes CDDA support for (all?) common programs. Will it ever be possible to use FreeBSD with e.g. kaudiocreator (needs cdparanoia)? I'm no friend of copying audiotracks by hand, give them a more or less apropriate name and feed them into any encoder. There were great tools which could do that automatically but they don't work any more for a reason I cannot follow. Best regards, -Harry pgp0.pgp Description: signature
Re: ACPI trouble with EPIA-M
On Wednesday 22 October 2003 22:22, Thorsten Greiner wrote: > Hi everybody, > > I have a VIA EPIA-M 1 board which works mostly when I disable > ACPI in the bios. Unfortunately the parallel port is controlled by > some Super-IO chip and is not recognized during boot. The same holds > true for serial ports and the floppy controller. > > When I enable ACPI in the bios the machine boots normally and > recognizes the parallel port BUT stops after displaying the hd/cdrom > identification , at the point where it would normally start init > (before the "Mounting root from ..." is displayed). > > At this point it just stops. I can break into DDB but nothing > else... Sorry, I can't help you but I'd like to confirm this. Since I don't need the ParPort my workarround was to disable the ParPort in the BIOS. Then I had no problems with ACPI. -Harry > > This machine is running a custom kernel based on GENERIC with > several device drivers removed and debugging stuff disabled (DDB is > still there), cvsupped Oct 17. There are no ACPI error messages > displayed during the boot process. > > I will happily provide more information on request. Please help me > to get this parallel port going as I want to hook up my printer > there. Thanks! > > Regards > -Thorsten pgp0.pgp Description: signature
Re: MBR zapped when panicking?
On Tuesday 21 October 2003 20:54, Kris Kennaway wrote: > On Tue, Oct 21, 2003 at 08:17:24PM +0200, Dimitry Andric wrote: > > Hi, > > > > Today I had a -CURRENT machine panic on me with a page fault, and > > something happened that I have seen before: the machine refused to > > come up afterwards. Closer inspection revealed that the MBR on the > > boot disk was totally zapped, filled with seemingly random characters. > > This is a known bug in the ATA driver. Tor Egge provided a workaround > patch here a few weeks ago. I didn't try it because I can't afford to > trash my disks like that again. Uhmm, at least a confirmation! Some weeks ago (03/09/18) I wrote the attached mail. Thanks, -Harry > > Kris From [EMAIL PROTECTED] Thu Sep 18 04:25:08 2003 From: Harald Schmalzbauer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: 5.1-rel deleted it's own MBR Date: Thu, 18 Sep 2003 04:25:08 +0200 User-Agent: KMail/1.5.3 X-Birthday: 06 Oktober 1972 X-Name: Harald Schmalzbauer X-Phone1: +49 (0) 163 555 3237 X-Phone2: +49 (0) 89 18947781 X-Address: Munich, 80686 X-Country: Germany MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_LeRa/eu3n+wIObY"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <[EMAIL PROTECTED]> Status: RO X-Status: S X-KMail-EncryptionState: X-KMail-SignatureState: --Boundary-02=_LeRa/eu3n+wIObY Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline Hi all, big mysterious bug is lingering somwhere. (Machine: C3, 256MB, 2x 30GB 2,5"= =20 IDE, SIL0680 controller) One of my drives failed with the following recovered from messages: Sep 16 01:47:44 tek kernel: ad4: WRITE command timeout tag=3D0 serv=3D0 -=20 resetting Sep 16 01:47:45 tek kernel: ata2: resetting devices .. Sep 16 01:47:45 tek kernel: ad4: removed from configuration Sep 16 01:47:45 tek kernel: ar0: WARNING - mirror lost Sep 16 01:47:45 tek kernel: ad4: deleted from ar0 disk0 Sep 16 01:47:45 tek kernel: done This was at 1:47 but the machine ran until about 5:30. Then it died (no=20 message!) When I tried to reboot, BIOS complained about missing MBR. And indeed, when= I=20 opened the server and connected the drives to another box, BOTH drives had = no=20 partition table I got a correct bsdlabel from both, ad6 and ad6s1. How can this happen? Bug in ata? Bug in GEOM? Nobody was loged in and also nobody can log in so the machine deleted it.=20 That's really sure! My fix was to use the fixit CD and wrote a new one with: fdisk -I -B -b /boot/boot1 ar0 fdisk -u ar0 (to change the starting sector from 63 to 0) fsck found a few errors but the server is up and running again. S=F8ren: I remember you're planning better RAID management support. Will it= be=20 possible to control the ar0 by the controller's BIOS in the future? When I rebuilt the array with the BIOS (which took 6 hours!) FreeBSD still= =20 reported a degraded RAID1! This was really annoying Thanks, =2DHarry --Boundary-02=_LeRa/eu3n+wIObY Content-Type: application/pgp-signature Content-Description: signature -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQA/aReLBylq0S4AzzwRAluJAJsFpTckdf4fiDhXELfIVvwInZNU5ACePNOH P7m44UKfnXxw7ioN/IGXDmg= =fh+e -END PGP SIGNATURE- --Boundary-02=_LeRa/eu3n+wIObY-- pgp0.pgp Description: signature
floppydisk broken?
Hi all, dmesg doesn't show anything unusual but trying to mount disks known to be good results in mount: /dev/fd0: Input/output error. Also fdformat does not work. It shows me every sector bad. Btw: How can I format a floppydisk in a USB-drive? fdformat /dev/da0 doesn't work. The USB-drive is fine, also is the standard floppy drive. I'm running FreeBSD 5.1-CURRENT #20: Sun Oct 12 23:31:45 CEST 2003 Thanks, -Harry pgp0.pgp Description: signature
It's time to get angry
Dear M$ users, PLEASE clean your systems. I get 15Megs of virus/day (~100 Mails each 150k with M$ trash). Now for over one week, so it's REALLY annoying. Not that there weren't enough great junk filters, it's wasted bandwidth. Not only on my site. If you have to use M$ systems on machines on which you take part in dicussions on FreeBSD-lists, please at least take care that you don't stress the others nerves too much. It's hard enough to read your "quoting". Don't know much about that worm/virus but I'm quiet sure just changing the mail client to something non-M$ would help (before the system were infected). So please format your infected discs, block all outgoing smtp connections, remove the hous' main fuse, whatever, try to stop that torture. -Harry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Getting -pthread support back into local source tree
Scot W. Hetzel wrote:
From: "Dan Naumov" <[EMAIL PROTECTED]>
Seeing as -pthread support has been removed from -CURRENT breaking
_LOTS_ of ports, is it possible to "get it back" into a local source
tree ? If so, how ? Thanks in advance.
All you need to do is add:
CONFIGURE_ENV+=PTHREAD_LIBS=${PTHREAD_LIBS} \
PTHREAD_CFLAGS=${PTHREAD_CFLAGS}
To the port that is broken by having -pthread support removed, then compile
the port.
If it still fails to compile, then you'll need to add a sed command to the
port that replaces -pthread with ${PTHREAD_LIBS} and -DTHREAD_SAFE with
${PTHREAD_LIBS} in the configure script or the Makefiles.
Well, that'd fit my skills, but what is for example with the jdk13? I
have no idea how to fix this one.
Thanks,
-Harry
After you have it working, send-pr your patch to gnats and the port
maintainer. This is the only way to get these problems fixed, if the port
maintainer doesn't have time to fix the port to work on -CURRENT.
Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ports and -current
Kris Kennaway wrote: On Sat, Sep 20, 2003 at 08:14:07AM +0200, Harald Schmalzbauer wrote: Well, for weeks now I couldn't compile (almost) any port. It seems that ports aren't tested against -current. Is that true? No. Not only the -pthread removement broke countless ports (some of them are easy to fix others aren't) also the entire new kde fails. Is there no aim to have ports running on -current? Also incorrect. The 4.9 ports freeze is holding up commits to fix compile failures on 5.1. Oh I see. Thats a reason. If I only knew about that freeze before my "pkg_delete -a" but that's just my problem Thanks, -Harry Kris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ports and -current
Well, for weeks now I couldn't compile (almost) any port. It seems that ports aren't tested against -current. Is that true? Not only the -pthread removement broke countless ports (some of them are easy to fix others aren't) also the entire new kde fails. Is there no aim to have ports running on -current? I'm asking because my "workstation" has enough resources to track -current to help testing. But if I breake ports with -current I won't keep tracking it. Thanks, -Harry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.1-rel deleted it's own MBR
Hi all, big mysterious bug is lingering somwhere. (Machine: C3, 256MB, 2x 30GB 2,5" IDE, SIL0680 controller) One of my drives failed with the following recovered from messages: Sep 16 01:47:44 tek kernel: ad4: WRITE command timeout tag=0 serv=0 - resetting Sep 16 01:47:45 tek kernel: ata2: resetting devices .. Sep 16 01:47:45 tek kernel: ad4: removed from configuration Sep 16 01:47:45 tek kernel: ar0: WARNING - mirror lost Sep 16 01:47:45 tek kernel: ad4: deleted from ar0 disk0 Sep 16 01:47:45 tek kernel: done This was at 1:47 but the machine ran until about 5:30. Then it died (no message!) When I tried to reboot, BIOS complained about missing MBR. And indeed, when I opened the server and connected the drives to another box, BOTH drives had no partition table I got a correct bsdlabel from both, ad6 and ad6s1. How can this happen? Bug in ata? Bug in GEOM? Nobody was loged in and also nobody can log in so the machine deleted it. That's really sure! My fix was to use the fixit CD and wrote a new one with: fdisk -I -B -b /boot/boot1 ar0 fdisk -u ar0 (to change the starting sector from 63 to 0) fsck found a few errors but the server is up and running again. Søren: I remember you're planning better RAID management support. Will it be possible to control the ar0 by the controller's BIOS in the future? When I rebuilt the array with the BIOS (which took 6 hours!) FreeBSD still reported a degraded RAID1! This was really annoying Thanks, -Harry pgp0.pgp Description: signature
Re: -pthread deprecated, but when?
On Tuesday 09 September 2003 06:23, leafy wrote: > IMO this deprecation deserves a place in UPDATING. And what are the > plans to Do The Right Thing? QT currently does not compile on -current > with the -pthread deprecated. Was port@ informed before the change? Not only qt isn't compiling any more on -current and I'm not sure if anybody is aware that ports can't be compiled on -current (at least the one I tried). Only the mozilla stuff has been patched so far. I'm also very interested what the plans are to Do The Right Thing. Thanks, -Harry > > Jiawei Ye pgp0.pgp Description: signature
Re: i386_set_ldt messages with today's world
On Monday 08 September 2003 03:26, Daniel Eischen wrote: > On Mon, 8 Sep 2003, Harald Schmalzbauer wrote: > > On Monday 08 September 2003 00:17, Eric Anholt wrote: > > > On Sun, 2003-09-07 at 14:13, Daniel Eischen wrote: > > > > On Sun, 7 Sep 2003, Harald Schmalzbauer wrote: > > > > *SCHNIP* > > > > > > > See the i386_set_ldt man page for more info > > > > > > > > Something is using i386_set_ldt() static ldt allocations. We > > > > added the warning message to detect usage of these allocations > > > > so they could be changed to dynamic allocations. > > > > > > > > Our threads libraries make use of LDTs on i386, so having > > > > other code also use (possibly) the same LDT would break > > > > things. > > > > > > > > > Only ode still exists which is: > > > > > 541 ?? S 0:15,50 /usr/X11R6/bin/XFree86 -auth > > > > > /var/run/xauth/A:0-2CitM > > > > > > > > What is ode? Typo? pid? > > > > > > > > I don't see how XFree86 can use i386_set_ldt(). It doesn't > > > > reference it on my box: > > > > > > > > $ nm /usr/X11R6/bin/XFree86 | grep ldt > > > > $ > > > > > > XFree86 loads various modules from /usr/X11R6/lib/modules. That said, > > > I could find nothing about ldts being used anywhere in the source > > > (grepping for LDT, sldt, and set_ldt). > > > > > > Perhaps the nvidia driver is being used? That's the only thing I could > > > think of. > > > > Yep, exactly that's the driver I'm using (GF4MX440-8) > > (I'm one of those without ANY problem with this card/driver (dualHead) > > btw.) > > Is this binary only or source? Either way, it needs to be changed > to use dynamic LDT allocations. Both. There is some sysctl stuff which gets compiled but the libGLcore.so etc. are binary only. I set [EMAIL PROTECTED] on the CC list. He's working on patches anyway, so he should be informed. Best regards, -Harry pgp0.pgp Description: signature
Re: i386_set_ldt messages with today's world
On Monday 08 September 2003 00:17, Eric Anholt wrote: > On Sun, 2003-09-07 at 14:13, Daniel Eischen wrote: > > On Sun, 7 Sep 2003, Harald Schmalzbauer wrote: *SCHNIP* > > > See the i386_set_ldt man page for more info > > > > Something is using i386_set_ldt() static ldt allocations. We > > added the warning message to detect usage of these allocations > > so they could be changed to dynamic allocations. > > > > Our threads libraries make use of LDTs on i386, so having > > other code also use (possibly) the same LDT would break > > things. > > > > > Only ode still exists which is: > > > 541 ?? S 0:15,50 /usr/X11R6/bin/XFree86 -auth > > > /var/run/xauth/A:0-2CitM > > > > What is ode? Typo? pid? > > > > I don't see how XFree86 can use i386_set_ldt(). It doesn't > > reference it on my box: > > > > $ nm /usr/X11R6/bin/XFree86 | grep ldt > > $ > > XFree86 loads various modules from /usr/X11R6/lib/modules. That said, I > could find nothing about ldts being used anywhere in the source > (grepping for LDT, sldt, and set_ldt). > > Perhaps the nvidia driver is being used? That's the only thing I could > think of. Yep, exactly that's the driver I'm using (GF4MX440-8) (I'm one of those without ANY problem with this card/driver (dualHead) btw.) Thanks, -Harry pgp0.pgp Description: signature
Re: i386_set_ldt messages with today's world
On Sunday 07 September 2003 23:13, Daniel Eischen wrote: *SNIP* > > Warning: pid 577 used static ldt allocation. > > See the i386_set_ldt man page for more info > > Something is using i386_set_ldt() static ldt allocations. We > added the warning message to detect usage of these allocations > so they could be changed to dynamic allocations. > > Our threads libraries make use of LDTs on i386, so having > other code also use (possibly) the same LDT would break > things. > > > Only ode still exists which is: > > 541 ?? S 0:15,50 /usr/X11R6/bin/XFree86 -auth > > /var/run/xauth/A:0-2CitM > > What is ode? Typo? pid? Typo. Only "one" PID is still listed. > > I don't see how XFree86 can use i386_set_ldt(). It doesn't > reference it on my box: > > $ nm /usr/X11R6/bin/XFree86 | grep ldt I also tried that and nothing returns. Had a look at man nm, but can't do anything with it. I'm no programmer. And first I'll have to get a "i386 Microprocessor Programmer's Reference Manual, Intel". Well, like mentioned I'm no programmer, I only wondered what this was and as far as I understood it's nothing I have to worry about, but unclear to you? Let me know if I can do anything helpful. Thanks, -Harry > $ pgp0.pgp Description: signature
i386_set_ldt messages with today's world
Hi all, I have no idea what it means, but since today's world I get the following messages after starting x: Warning: pid 541 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 547 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 548 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 567 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 568 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 569 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 570 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 573 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 572 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 577 used static ldt allocation. See the i386_set_ldt man page for more info Only ode still exists which is: 541 ?? S 0:15,50 /usr/X11R6/bin/XFree86 -auth /var/run/xauth/A:0-2CitM Thanks, -Harry pgp0.pgp Description: signature
