Re: Time to kill fdc ?
Content-Type: text/plain; charset=ISO-8859-1 In message <51180545.8030...@hesiod.org>, Jeff Anton writes: >Please keep fdc. If it works for everybody else, no worries, I wont touch it. I'm just surprised my experience is so different from everybody else... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
Content-Type: text/plain; charset=ISO-8859-1 In message <20130210173150.ga77...@troutmask.apl.washington.edu>, Steve Kargl w rites: >> Have you submitted bugs? :) > >No. At the time, I was more concerned with returning my laptop >to some functioning form [...] Steve, First a hat-tip for even doing this in the first place, if more committers ran -current, -current would work better. Second, I wrote src/tools/tools/sysbuild to specifically address the issue of being able to work, while running -current. sysbuild allows you to build your system into an empty partition while you're working (= good test of scheduler btw), then test boot the new system, and fall back to the old if it caused too much trouble. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
I've ran 8-CURRENT amd64 desktop which evolved to 8-STABLE and 9-STABLE now, without real deal breakers. All rougher edges I reckon from -CURRENT days gradually went away, but system was very usable then too. -- View this message in context: http://freebsd.1045724.n5.nabble.com/7-days-of-dogfood-tp5785452p5785794.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
Hi, On Sun, 10 Feb 2013 15:57:01 +0100 Erik Cederstrand wrote: > Den 10/02/2013 kl. 02.30 skrev Erich Dollansky > : > > > I am on dog food since last May/June. How should I phrase it? Every > > can tastes different. Most cans have a perfect taste but some cans > > are really off. > > And as long as there is no automatic can taster doing quality > assurance of the produced cans, then foul cans will go unnoticed > until a dog pukes all over the carpet :-) > Isn't this the idea of HEAD? > For this to change, we really need to catch up on years of neglect in > e.g. src/tools/regression/. I really applaud the people doing the > thankless job of changing this. > I do not believe that this all can be automated. Erich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
Please keep fdc. I have many machines which still have working drives and only last month I used one to make a bootable to update a machines boot prom. I've even got 5 1/2" disk which still work. (Original MSDOS 5.0 and Windows 3.1 disks...) atlas.hesiod.org:root[1]: dd if=/dev/fd0 of=/dev/null bs=32k 45+0 records in 45+0 records out 1474560 bytes transferred in 48.169721 secs (30612 bytes/sec) atlas.hesiod.org:root[2]: uname -a FreeBSD atlas.hesiod.org 9.1-RELEASE FreeBSD 9.1-RELEASE #1 r244037: Fri Dec 21 15:09:03 PST 2012 r...@atlas.hesiod.org:/usr/src/sys/amd64/compile/ATLAS amd64 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On 02/10/13 15:55, Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=ISO-8859-1 > > In message <5117a0cd.6060...@beastielabs.net>, Hans Ottevanger writes: >> On 02/10/13 12:46, Daniel O'Connor wrote: > >> But I just did an experiment on an old Pentium 4 system here, using the >> fdc driver and 8.3-STABLE as of early December (r243900). I read several >> diskettes using "dd /dev/fd0 /dev/null" and everything went flawlessly. > > Could you try: > > dd if=/dev/fd0 of=/dev/null bs=1048576 > Tried this, 20 times in a row, without any failures. Did the same for dd if=/dev/fd0 of=/tmp/junk bs=1048576 again without failures. As stated before, this is on an old Pentium 4, now updated to 8.3-STABLE r246624. What hardware are you using? Maybe I can reproduce that panic if I can find similar hardware in my "collection". > That consistently exploded 7.x and 8.x here yesterday... > > (I used recoverdisk, but that's not material) > >> Could it be that the drive that Poul-Henning is using is worn out a bit? > > No, that's not it. It's (amongst other things) ISA-DMA being > børken (try something different that /dev null btw :-) and bounce > buffers for same panicking the system. > Kind regards, Hans ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
>> Poul-Henning Kamp wrote: > > I tried to read a floppy disk yesterday. > > When was the last time anybody tried that with a FreeBSD release ? > > Based on my brief experiments yesterday, 6.X is the last release > where accessing floppy disks carry less than a 10% risk of a panic. > > Unless somebody fixes the fdc driver to work in -current, I intend > to dust of my axe and cut it from the tree later this spring. Yes, I did try at the time 9 was current (to make fancy DOS floppies for BIOS for the old machine). I remember I only had an issue with PCMCIA-attached floppy drive (that uses fdc(4) afair), which didn't work then (but I am user I used those long time ago). Maybe the issue you are seeing is similar to my PCMCIA-based floppy problem - I'd be happy to have it fixed for recovery of old boxes. (Will test -current on my ancient box tomorrow) //Marcin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
On Sun, Feb 10, 2013 at 07:24:03PM +, Anton Shterenlikht wrote: > From s...@troutmask.apl.washington.edu Sun Feb 10 19:06:10 2013 > On Sun, Feb 10, 2013 at 06:51:23PM +, Anton Shterenlikht wrote: > > Date: Sun, 10 Feb 2013 08:44:24 -0800 > > From: Steve Kargl > > To: Boris Samorodov > > Subject: Re: 7+ days of dogfood > > > > > > FFLAGS = -O2 -pipe -march=native -mtune=native > > > > > > I don't like using "=" for FLAGS at make.conf... > > > > > > > FFLAGS+= -funroll-loops -ftree-vectorize > > > > > > ... as well as defaults overriding. > > > > > > > FFLAGS are the options used while compiling Fortran. Having > > spent years contributing to and testing gfortran, I am fairly > > comfortable with these options. > > > > Do you recommend these FFLAGS settings to all > > users of gfortran (via lang/gcc4x)? > > Yes. > > And for all arches? I use ia64, sparc64 and amd64. > I use these on amd64 and i386 arches. I rarely use spacr64 (mainly for development of ld128 libm functions) and never use ia64. Choose one of your codes and test. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
From s...@troutmask.apl.washington.edu Sun Feb 10 19:06:10 2013 On Sun, Feb 10, 2013 at 06:51:23PM +, Anton Shterenlikht wrote: > Date: Sun, 10 Feb 2013 08:44:24 -0800 > From: Steve Kargl > To: Boris Samorodov > Subject: Re: 7+ days of dogfood > > > > FFLAGS = -O2 -pipe -march=native -mtune=native > > > > I don't like using "=" for FLAGS at make.conf... > > > > > FFLAGS+= -funroll-loops -ftree-vectorize > > > > ... as well as defaults overriding. > > > > FFLAGS are the options used while compiling Fortran. Having > spent years contributing to and testing gfortran, I am fairly > comfortable with these options. > > Do you recommend these FFLAGS settings to all > users of gfortran (via lang/gcc4x)? > Yes. And for all arches? I use ia64, sparc64 and amd64. > For example, I use blas, lapack, slatec, atlas, etc. > Should I use these FFLAGS too? Without knowing what options you currently use, I cannot make a concrete recommendation other than I've extensive tested the above options with my own codes and the Polyhedron testsuite. Oh, I do recommend that one should avoid -ffast-math (unless one really understands what it actually does). Many thanks Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
On Sun, Feb 10, 2013 at 06:51:23PM +, Anton Shterenlikht wrote: > Date: Sun, 10 Feb 2013 08:44:24 -0800 > From: Steve Kargl > To: Boris Samorodov > Subject: Re: 7+ days of dogfood > > > > FFLAGS = -O2 -pipe -march=native -mtune=native > > > > I don't like using "=" for FLAGS at make.conf... > > > > > FFLAGS+= -funroll-loops -ftree-vectorize > > > > ... as well as defaults overriding. > > > > FFLAGS are the options used while compiling Fortran. Having > spent years contributing to and testing gfortran, I am fairly > comfortable with these options. > > Do you recommend these FFLAGS settings to all > users of gfortran (via lang/gcc4x)? > Yes. > For example, I use blas, lapack, slatec, atlas, etc. > Should I use these FFLAGS too? Without knowing what options you currently use, I cannot make a concrete recommendation other than I've extensive tested the above options with my own codes and the Polyhedron testsuite. Oh, I do recommend that one should avoid -ffast-math (unless one really understands what it actually does). -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
Date: Sun, 10 Feb 2013 08:44:24 -0800 From: Steve Kargl To: Boris Samorodov Subject: Re: 7+ days of dogfood > > FFLAGS = -O2 -pipe -march=native -mtune=native > > I don't like using "=" for FLAGS at make.conf... > > > FFLAGS+= -funroll-loops -ftree-vectorize > > ... as well as defaults overriding. > FFLAGS are the options used while compiling Fortran. Having spent years contributing to and testing gfortran, I am fairly comfortable with these options. Do you recommend these FFLAGS settings to all users of gfortran (via lang/gcc4x)? For example, I use blas, lapack, slatec, atlas, etc. Should I use these FFLAGS too? Thanks Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On Sun, Feb 10, 2013 at 3:53 PM, Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=ISO-8859-1 > > In message > > , "C. P. Ghost" writes: >>On Sun, Feb 10, 2013 at 2:28 PM, Poul-Henning Kamp >>wrote: > >>I was thinking of physical fdc(4). Is there a published interface >>to access the hardware, i.e. to tunnel the commands and return >>values to and from the device? Something like pass(4) but for >>floppies? That way, fdc could be moved to user space and more >>easily debugged. > > Look at /dev/io. Yes, excellent! That was exactly what I was looking for. Thank you. > But seriously: All our old releases are available on the net, > 4.11 and 6.2 were both great releases and they have wonderful > floppy support. Sure, there's always a way to read old floppies, it is just not as convenient. We should really fix any problems with fdc(4) though (as in "please please please"). ;-) > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On Sun, Feb 10, 2013 at 7:03 PM, Poul-Henning Kamp wrote: >>> Could you try: >>> >>> dd if=/dev/fd0 of=/dev/null bs=1048576 >>> >>> That consistently exploded 7.x and 8.x here yesterday... >> >>FWIW, >> >>NO problem here, with: >> >>7.4-STABLE 244498 i386 PII >>8.3-STABLE 243778 i386 P4 >>10.0-CURRENT 245422 i386 P4 (same system) > > That's interesting, that's entirely counter to what I saw > on two different systems yesterday. > > I'll try again on a third system. > >>I do not have floppies on my 9.X / amd64 systems > > Last I tried, amd64 systems consistently returned garbage > when reading floppies with ISA-DMA. > > I'd be interested to hear other peoples results ? I'll try that later on my 9.1/amd64 box and will report back. Right now, I've got a long-running computation that I'd rather not interrupt, should the machine crash. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
Content-Type: text/plain; charset=ISO-8859-1 In message <5117daa6.4000...@orange.fr>, Claude Buisson writes: >> Could you try: >> >> dd if=/dev/fd0 of=/dev/null bs=1048576 >> >> That consistently exploded 7.x and 8.x here yesterday... > >FWIW, > >NO problem here, with: > >7.4-STABLE 244498 i386 PII >8.3-STABLE 243778 i386 P4 >10.0-CURRENT 245422 i386 P4 (same system) That's interesting, that's entirely counter to what I saw on two different systems yesterday. I'll try again on a third system. >I do not have floppies on my 9.X / amd64 systems Last I tried, amd64 systems consistently returned garbage when reading floppies with ISA-DMA. I'd be interested to hear other peoples results ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On 02/10/2013 15:55, Poul-Henning Kamp wrote: Content-Type: text/plain; charset=ISO-8859-1 In message<5117a0cd.6060...@beastielabs.net>, Hans Ottevanger writes: On 02/10/13 12:46, Daniel O'Connor wrote: But I just did an experiment on an old Pentium 4 system here, using the fdc driver and 8.3-STABLE as of early December (r243900). I read several diskettes using "dd /dev/fd0 /dev/null" and everything went flawlessly. Could you try: dd if=/dev/fd0 of=/dev/null bs=1048576 That consistently exploded 7.x and 8.x here yesterday... FWIW, NO problem here, with: 7.4-STABLE 244498 i386 PII 8.3-STABLE 243778 i386 P4 10.0-CURRENT 245422 i386 P4 (same system) I do not have floppies on my 9.X / amd64 systems CBu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
On Sun, Feb 10, 2013 at 09:05:22AM -0800, Adrian Chadd wrote: > On 10 February 2013 08:44, Steve Kargl > wrote: > > > Without it, the build infrastructure was selecting -march=i486, > > which produced even worse results. Several ports would not > > compile because llvm's integrated assembler was given invalid > > assembly constructs. > > Have you submitted bugs? :) > No. At the time, I was more concerned with returning my laptop to some functioning form than worrying about why building xfig was dying with an invalid assembly instruction. I also don't see a point in submitting a bug report of the form 'Firefox dies with a segfault after 10 seconds' when I can obtain no other useful information. In particular, bin/112408 suggests a bug report about firefox would be enshrined in the PR database. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
On 10 February 2013 08:44, Steve Kargl wrote: > Without it, the build infrastructure was selecting -march=i486, > which produced even worse results. Several ports would not > compile because llvm's integrated assembler was given invalid > assembly constructs. Have you submitted bugs? :) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
On Sun, Feb 10, 2013 at 05:39:37PM +0400, Boris Samorodov wrote: > 10.02.2013 04:07, Steve Kargl ??: > > As for me I use CURRENT at my JOB for many years now. > I used to i386 but switched to amd64 at the end of 2012. > The system (both world and kernel) are updated every > week or two. > My workstation at work is amd64 and I have a 20 node amd64 cluster. All of these systems run freebsd-current. I've only had a few problems when building ports. > > One option that I use has been already mentioned -- MALLOC_PRODUCTION. > > > CPUTYPE?=core2 > > I never use this option. It was very long ago that I was > beaten by it, but don't like it since. Without it, the build infrastructure was selecting -march=i486, which produced even worse results. Several ports would not compile because llvm's integrated assembler was given invalid assembly constructs. > > FFLAGS = -O2 -pipe -march=native -mtune=native > > I don't like using "=" for FLAGS at make.conf... > > > FFLAGS+= -funroll-loops -ftree-vectorize > > ... as well as defaults overriding. > FFLAGS are the options used while compiling Fortran. Having spent years contributing to and testing gfortran, I am fairly comfortable with these options. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
on 10/02/2013 13:06 Poul-Henning Kamp said the following: > > I tried to read a floppy disk yesterday. > > When was the last time anybody tried that with a FreeBSD release ? > > Based on my brief experiments yesterday, 6.X is the last release > where accessing floppy disks carry less than a 10% risk of a panic. > > Unless somebody fixes the fdc driver to work in -current, I intend > to dust of my axe and cut it from the tree later this spring. Is this an overreaction or just a wrong kind of reaction? :-) -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: geli(8) breaks after a couple hours of uptime
on 10/02/2013 17:44 Pawel Jakub Dawidek said the following: > On Sun, Feb 10, 2013 at 09:50:58AM +0200, Andriy Gapon wrote: >> on 10/02/2013 01:35 Pawel Jakub Dawidek said the following: >>> geli(8) almost exclusively deals with sensitive data. Even mlocking >>> MAXPHYS would fail with current limits, but this is bad idea. >>> >>> With mlockall() I am sure I didn't miss anything - be it forgetting >>> about mlocking some buffer or zeroing it before munlock. I'm also sure >>> someone else who can modify geli(8) in the future won't miss anything >>> too. >> >> Well, the geli is not such a complex program really. It seems to use only >> two >> or so buffers for sensitive data. [...] > > Maybe it isn't very complex, but complex enough that you missed a dozen > or so buffers that would need mlocking (almost everything that is > bzero'ed), I haven't exactly missed them, because I only glanced over the code. > not to mention internal states for hash and encryption > algorithms that operate on blocks, so they can keep plain data until > their update method gather entire block. Encryption and HMAC calculation > is done by API used by both userland and kernel parts, so it would need > some ifdefs to make it work, thus further complicating entire thing. I think that things such as these are better be done in externally provided/controlled buffers. >> [...] As far as I can see geli deals only with some >> key management (reading keys, generating key from key material, etc). There >> is >> definitely no need to mlock the code, etc. > > I fully agree there is no need to mlock the code and I'd be happy to use > mlockall(2) flag that protects only the data. Until such flag is > introduced I'll keep mlocking everything. > >> I think that PAGE_SIZE (or at most a small multiple of it) should be >> sufficient. >> I don't think that we currently have (or expect to see in the near future) >> algorithms where keys with more than 4096 size provide any additional >> security. > > geli(8) deals just fine with files that are larger than buffers, so even > with smaller buffer it can read the data in few steps. > > The proposed patch is here if someone would like to give it a try: > > http://people.freebsd.org/~pjd/patches/geom_eli.c.patch > This is a very good start, IMHO. Thank you. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
On Sun, Feb 10, 2013 at 1:07 AM, Steve Kargl wrote: > In a long thread started by Peter Wemm on developers@, he described > the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10. A > part of his description included the need to test top-of-tree under > actual real-world conditions. In his words, FreeBSD should "eat its > own dogfood." The new installation on FreeBSD.org, of course, would > test FreeBSD-10 under (heavy) server load. Just one word from an ordinary user - this is perfect idea to test things in the real world scenario in a dedicated environment because this will show problems and force solutions very quickly. Some more serious tasks may be also a good playground to test stability of the stable branch and make sure they will not propagate issues to the production stable platforms around the world. I really love FreeBSD for the clean, simple and elegant yet still very powerful solutions. Some features are still behind, some features are pioneer, still smart and experienced personnel decisions behind the scenes produces impressive results. I am sure this is also a good decision. This is why I stick and promote the FreeBSD, although some people don't like it, and I even consider to switch to CURRENT in everyday tasks too if this will help your work with necessary feedback :-) Best regards :-) Tomek Cedro -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: geli(8) breaks after a couple hours of uptime
On Sun, Feb 10, 2013 at 09:50:58AM +0200, Andriy Gapon wrote: > on 10/02/2013 01:35 Pawel Jakub Dawidek said the following: > > geli(8) almost exclusively deals with sensitive data. Even mlocking > > MAXPHYS would fail with current limits, but this is bad idea. > > > > With mlockall() I am sure I didn't miss anything - be it forgetting > > about mlocking some buffer or zeroing it before munlock. I'm also sure > > someone else who can modify geli(8) in the future won't miss anything > > too. > > Well, the geli is not such a complex program really. It seems to use only two > or so buffers for sensitive data. [...] Maybe it isn't very complex, but complex enough that you missed a dozen or so buffers that would need mlocking (almost everything that is bzero'ed), not to mention internal states for hash and encryption algorithms that operate on blocks, so they can keep plain data until their update method gather entire block. Encryption and HMAC calculation is done by API used by both userland and kernel parts, so it would need some ifdefs to make it work, thus further complicating entire thing. > [...] As far as I can see geli deals only with some > key management (reading keys, generating key from key material, etc). There is > definitely no need to mlock the code, etc. I fully agree there is no need to mlock the code and I'd be happy to use mlockall(2) flag that protects only the data. Until such flag is introduced I'll keep mlocking everything. > I think that PAGE_SIZE (or at most a small multiple of it) should be > sufficient. > I don't think that we currently have (or expect to see in the near future) > algorithms where keys with more than 4096 size provide any additional > security. geli(8) deals just fine with files that are larger than buffers, so even with smaller buffer it can read the data in few steps. The proposed patch is here if someone would like to give it a try: http://people.freebsd.org/~pjd/patches/geom_eli.c.patch -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpm_Gk3PBtuD.pgp Description: PGP signature
Re: Time to kill fdc ?
Content-Type: text/plain; charset=ISO-8859-1 In message <20130210141340.GA96183@klump.hjerdalen.lokalnett>, Eivind Evensen w rites: >Apart from lots of seeking (for which I don't understand the reason) when >closing the device in DD mode, I don't have any problems with it. That's the geomclasses tasting it for labels, mirrors, mbr's etc. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On Sun, Feb 10, 2013 at 11:06:44AM +, Poul-Henning Kamp wrote: > > I tried to read a floppy disk yesterday. > > When was the last time anybody tried that with a FreeBSD release ? > > Based on my brief experiments yesterday, 6.X is the last release > where accessing floppy disks carry less than a 10% risk of a panic. > > Unless somebody fixes the fdc driver to work in -current, I intend > to dust of my axe and cut it from the tree later this spring. I'm using DD disks about every other day and HD disks about once a week. Apart from lots of seeking (for which I don't understand the reason) when closing the device in DD mode, I don't have any problems with it. This is on 8.3-PRERELEASE. I really hope the driver will stay. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
Den 10/02/2013 kl. 02.30 skrev Erich Dollansky : > I am on dog food since last May/June. How should I phrase it? Every can > tastes different. Most cans have a perfect taste but some cans are > really off. And as long as there is no automatic can taster doing quality assurance of the produced cans, then foul cans will go unnoticed until a dog pukes all over the carpet :-) For this to change, we really need to catch up on years of neglect in e.g. src/tools/regression/. I really applaud the people doing the thankless job of changing this. Erik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
Content-Type: text/plain; charset=ISO-8859-1 In message <5117a0cd.6060...@beastielabs.net>, Hans Ottevanger writes: >On 02/10/13 12:46, Daniel O'Connor wrote: >But I just did an experiment on an old Pentium 4 system here, using the >fdc driver and 8.3-STABLE as of early December (r243900). I read several >diskettes using "dd /dev/fd0 /dev/null" and everything went flawlessly. Could you try: dd if=/dev/fd0 of=/dev/null bs=1048576 That consistently exploded 7.x and 8.x here yesterday... (I used recoverdisk, but that's not material) >Could it be that the drive that Poul-Henning is using is worn out a bit? No, that's not it. It's (amongst other things) ISA-DMA being børken (try something different that /dev null btw :-) and bounce buffers for same panicking the system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
Content-Type: text/plain; charset=ISO-8859-1 In message , "C. P. Ghost" writes: >On Sun, Feb 10, 2013 at 2:28 PM, Poul-Henning Kamp wrote: >I was thinking of physical fdc(4). Is there a published interface >to access the hardware, i.e. to tunnel the commands and return >values to and from the device? Something like pass(4) but for >floppies? That way, fdc could be moved to user space and more >easily debugged. Look at /dev/io. But seriously: All our old releases are available on the net, 4.11 and 6.2 were both great releases and they have wonderful floppy support. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Reminder: FreeBSD Quarterly Status Reports, July--December, 2012
Hello there, Let me call your attention to the approaching deadline of the next set(s) of FreeBSD Quarterly Status Reports. Please consider submitting a few lines on your FreeBSD-related project, we are counting on all of you! :-) On Sun, Jan 13, 2013 at 10:57 PM, Gabor Pali wrote: >Please note that the deadline for submissions covering the period >between July and December 2012 is February 17th, 2013. You can find more details on submission at the Project's web site [1] but you are free to ask me directly (in private) if you need help with this. [1] http://www.freebsd.org/news/status/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On Sun, Feb 10, 2013 at 1:28 PM, Fbsd8 wrote: > Floppy drive support was removed from Freebsd around release 7.0 I think. > Read the release-notes for 6.0, 7.0 and 8.0 to determine when it happened. Nope, floppy support is still there, and AFAICS it is working just fine: Script started on Sun Feb 10 15:21:07 2013 root@phenom:~ # uname -a FreeBSD phenom.cordula.ws 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r244903: Mon Dec 31 15:14:32 CET 2012 r...@phenom.cordula.ws:/usr/obj/usr/src/sys/GENERIC amd64 root@phenom:~ # fdformat /dev/fd0 Format 1440K floppy `/dev/fd0'? (y/n): y Processing done. root@phenom:~ # newfs /dev/fd0 /dev/fd0: 1.4MB (2880 sectors) block size 32768, fragment size 4096 using 2 cylinder groups of 1.00MB, 32 blks, 128 inodes. super-block backups (for fsck_ffs -b #) at: 192, 2240 root@phenom:~ # mount /dev/fd0 /mnt root@phenom:~ # df -h /mnt FilesystemSizeUsed Avail Capacity Mounted on /dev/fd0 1.1M8.0k1.0M 1%/mnt root@phenom:~ # cp /usr/include/sys/_*.h /mnt root@phenom:~ # sync root@phenom:~ # df -h /mnt FilesystemSizeUsed Avail Capacity Mounted on /dev/fd0 1.1M112k948k11%/mnt root@phenom:~ # ls /mnt .snap _null.h _sx.h _bus_dma.h _pthreadtypes.h _task.h _callout.h _rmlock.h _termios.h _cpuset.h _rwlock.h _timespec.h _iovec.h_semaphore.h_timeval.h _kstack_cache.h _sigset.h _types.h _lock.h _sockaddr_storage.h _umtx.h _lockmgr.h _stack.h _mutex.h_stdint.h root@phenom:~ # umount /mnt root@phenom:~ # exit exit Script done on Sun Feb 10 15:26:10 2013 This was with an 10+ years old 1.44MB floppy that I had lying around here, on FreeBSD/amd64 9.1 r244903. It would be a shame to axe that code. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
Claude Buisson wrote: On 02/10/2013 13:28, Fbsd8 wrote: Poul-Henning Kamp wrote: I tried to read a floppy disk yesterday. When was the last time anybody tried that with a FreeBSD release ? Based on my brief experiments yesterday, 6.X is the last release where accessing floppy disks carry less than a 10% risk of a panic. Unless somebody fixes the fdc driver to work in -current, I intend to dust of my axe and cut it from the tree later this spring. Floppy drive support was removed from Freebsd around release 7.0 I think. Read the release-notes for 6.0, 7.0 and 8.0 to determine when it happened. Is this a joke ?? Script started on Sun Feb 10 14:47:20 2013 root@fidel:~ # uname -a FreeBSD fidel 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Fri Jan 18 17:45:10 CET 2013 toor@fidel:/usr/obj/home/src/sys/ADELE10X i386 root@fidel:~ # mount_msdosfs /dev/fd0 /floppy root@fidel:~ # ll /floppy total 341 -rw-rw-r-- 1 root operator 1851 Aug 15 2011 licence.txt -rw-rw-r-- 1 root operator 79175 Aug 15 2011 liesmich.html -rw-rw-r-- 1 root operator 70564 Aug 15 2011 liesmich.txt -rw-rw-r-- 1 root operator 43319 Sep 15 2011 plpbt.bin -rw-rw-r-- 1 root operator 81846 Aug 15 2011 readme.html -rw-rw-r-- 1 root operator 71509 Aug 15 2011 readme.txt root@fidel:~ # umount /floppy root@fidel:~ # dd if=/dev/fd0 of=floppy.img 2880+0 records in 2880+0 records out 1474560 bytes transferred in 48.027444 secs (30702 bytes/sec) root@fidel:~ # mount_msdosdfs /dev/fd0 /floppy root@fidel:~ # ll /floppy total 0 root@fidel:~ # umount /floppy root@fidel:~ # dd if=floppy.img of=/dev/fd0 2880+0 records in 2880+0 records out 1474560 bytes transferred in 47.829774 secs (30829 bytes/sec) root@fidel:~ # mount_msdosfs /dev/fd0 /floppy root@fidel:~ # ll /floppy total 341 -rw-rw-r-- 1 root operator 1851 Aug 15 2011 licence.txt -rw-rw-r-- 1 root operator 79175 Aug 15 2011 liesmich.html -rw-rw-r-- 1 root operator 70564 Aug 15 2011 liesmich.txt -rw-rw-r-- 1 root operator 43319 Sep 15 2011 plpbt.bin -rw-rw-r-- 1 root operator 81846 Aug 15 2011 readme.html -rw-rw-r-- 1 root operator 71509 Aug 15 2011 readme.txt root@fidel:~ # rm /floppy/* root@fidel:~ # umount /floppy with a 10 years old drive, and >10 years old floppies.. yes, there can be i/o errors with such media CBu My bad it was floppy install media that was dropped. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On 02/10/2013 13:28, Fbsd8 wrote: Poul-Henning Kamp wrote: I tried to read a floppy disk yesterday. When was the last time anybody tried that with a FreeBSD release ? Based on my brief experiments yesterday, 6.X is the last release where accessing floppy disks carry less than a 10% risk of a panic. Unless somebody fixes the fdc driver to work in -current, I intend to dust of my axe and cut it from the tree later this spring. Floppy drive support was removed from Freebsd around release 7.0 I think. Read the release-notes for 6.0, 7.0 and 8.0 to determine when it happened. Is this a joke ?? Script started on Sun Feb 10 14:47:20 2013 root@fidel:~ # uname -a FreeBSD fidel 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Fri Jan 18 17:45:10 CET 2013 toor@fidel:/usr/obj/home/src/sys/ADELE10X i386 root@fidel:~ # mount_msdosfs /dev/fd0 /floppy root@fidel:~ # ll /floppy total 341 -rw-rw-r-- 1 root operator 1851 Aug 15 2011 licence.txt -rw-rw-r-- 1 root operator 79175 Aug 15 2011 liesmich.html -rw-rw-r-- 1 root operator 70564 Aug 15 2011 liesmich.txt -rw-rw-r-- 1 root operator 43319 Sep 15 2011 plpbt.bin -rw-rw-r-- 1 root operator 81846 Aug 15 2011 readme.html -rw-rw-r-- 1 root operator 71509 Aug 15 2011 readme.txt root@fidel:~ # umount /floppy root@fidel:~ # dd if=/dev/fd0 of=floppy.img 2880+0 records in 2880+0 records out 1474560 bytes transferred in 48.027444 secs (30702 bytes/sec) root@fidel:~ # mount_msdosdfs /dev/fd0 /floppy root@fidel:~ # ll /floppy total 0 root@fidel:~ # umount /floppy root@fidel:~ # dd if=floppy.img of=/dev/fd0 2880+0 records in 2880+0 records out 1474560 bytes transferred in 47.829774 secs (30829 bytes/sec) root@fidel:~ # mount_msdosfs /dev/fd0 /floppy root@fidel:~ # ll /floppy total 341 -rw-rw-r-- 1 root operator 1851 Aug 15 2011 licence.txt -rw-rw-r-- 1 root operator 79175 Aug 15 2011 liesmich.html -rw-rw-r-- 1 root operator 70564 Aug 15 2011 liesmich.txt -rw-rw-r-- 1 root operator 43319 Sep 15 2011 plpbt.bin -rw-rw-r-- 1 root operator 81846 Aug 15 2011 readme.html -rw-rw-r-- 1 root operator 71509 Aug 15 2011 readme.txt root@fidel:~ # rm /floppy/* root@fidel:~ # umount /floppy with a 10 years old drive, and >10 years old floppies.. yes, there can be i/o errors with such media CBu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
10.02.2013 04:07, Steve Kargl пишет: As for me I use CURRENT at my JOB for many years now. I used to i386 but switched to amd64 at the end of 2012. The system (both world and kernel) are updated every week or two. I had switched to clang very early. There were problems with ports I used but not now: gimp, inkscape, scribus, texlive, thunderbird, firefox, libreoffice (didn't try the latest version, ENOTIME). One option that I abandoned was WITH_LIBCPLUSPLUS. I tried it last summer but the system went very unstable. Didn't have a chance to test it since then. One option that I use has been already mentioned -- MALLOC_PRODUCTION. > CPUTYPE?=core2 I never use this option. It was very long ago that I was beaten by it, but don't like it since. > FFLAGS = -O2 -pipe -march=native -mtune=native I don't like using "=" for FLAGS at make.conf... > FFLAGS+= -funroll-loops -ftree-vectorize ... as well as defaults overriding. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On 02/10/13 12:46, Daniel O'Connor wrote: > > On 10/02/2013, at 22:14, Poul-Henning Kamp wrote: >>> I've used it in 7.x to read install.cfg for a semi automated install >>> process. >>> >>> I didn't see any panics, but then again install.cfg is a pretty small file. >> >> On 7.x I got consistent panics about bounce-buffers. > > > Hmm strange, I am not sure I have requisite hardware at work any more, all of > the suitable machines were shipped. > > In any case I am in no position to maintain FDC as I no longer user it as > part of my install process. > > -- I still use those old 1.4 Mbyte diskettes quite often (ancient archives of experimental data, exchanging data with retro-computers, etc.), but these days I mostly (but not always) use a USB diskette drive. But I just did an experiment on an old Pentium 4 system here, using the fdc driver and 8.3-STABLE as of early December (r243900). I read several diskettes using "dd /dev/fd0 /dev/null" and everything went flawlessly. The only issue I have seen with fdc over the years/releases is that around 7.x old DD diskettes (maximum of 720 kbyte) stopped working. Attempting to write them failed with a lot of retries, but never resulted in a panic. Strange enough they do work with my USB drive ... Could it be that the drive that Poul-Henning is using is worn out a bit? Not that the system should be panicking in that case, but it could at least explain why we see different thing happening. Kind regards, Hans ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On Sun, Feb 10, 2013 at 2:28 PM, Poul-Henning Kamp wrote: >>> Unless somebody fixes the fdc driver to work in -current, I intend >>> to dust of my axe and cut it from the tree later this spring. >> >>Any chance to get a user-mode fdc(4) replacement then? Maybe >>in ports? > > Uhm, just how would that work ? > > If you just want virtual floppies, md(4) is your driver... I was thinking of physical fdc(4). Is there a published interface to access the hardware, i.e. to tunnel the commands and return values to and from the device? Something like pass(4) but for floppies? That way, fdc could be moved to user space and more easily debugged. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
Content-Type: text/plain; charset=ISO-8859-1 In message , "C. P. Ghost" writes: >> Unless somebody fixes the fdc driver to work in -current, I intend >> to dust of my axe and cut it from the tree later this spring. > >Any chance to get a user-mode fdc(4) replacement then? Maybe >in ports? Uhm, just how would that work ? If you just want virtual floppies, md(4) is your driver... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On Sun, Feb 10, 2013 at 12:06 PM, Poul-Henning Kamp wrote: > > I tried to read a floppy disk yesterday. > > When was the last time anybody tried that with a FreeBSD release ? > > Based on my brief experiments yesterday, 6.X is the last release > where accessing floppy disks carry less than a 10% risk of a panic. > > Unless somebody fixes the fdc driver to work in -current, I intend > to dust of my axe and cut it from the tree later this spring. Any chance to get a user-mode fdc(4) replacement then? Maybe in ports? -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
Content-Type: text/plain; charset=ISO-8859-1 In message <5117927c.8090...@a1poweruser.com>, Fbsd8 writes: >Floppy drive support was removed from Freebsd around release 7.0 I >think. Read the release-notes for 6.0, 7.0 and 8.0 to determine when it >happened. I think you are confusing "installing from floppies" with "has a device-driver for floppies" -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: Time to kill fdc ?
On Sun, 10 Feb 2013, Poul-Henning Kamp wrote: > I tried to read a floppy disk yesterday. > > When was the last time anybody tried that with a FreeBSD release ? > I did it last week on 9.0-R. Worked great. (I have more than plans to continue supporting floppies -- I've actually written code in the past 3 weeks supporting floppies as a test-case called for it; commit still pending) > Based on my brief experiments yesterday, 6.X is the last release > where accessing floppy disks carry less than a 10% risk of a panic. > > Unless somebody fixes the fdc driver to work in -current, I intend > to dust of my axe and cut it from the tree later this spring. I was using 9.0-R, admittedly far from -CURRENT. Sad because my up-coming HEAD commit was tested on 9.0-R -- if fdc is broken in CURRENT I need to rethink things (especially if you're dusting off your axe). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: some usb troubles
On Sunday 10 February 2013 12:20:44 Konstantin Belousov wrote: > On Sun, Feb 10, 2013 at 12:03:36PM +0100, Hans Petter Selasky wrote: > > On Saturday 09 February 2013 19:01:25 Chagin Dmitry wrote: > > > Hi all, > > > > > > trying to run macbookpro10,1 on HEAD: > > > > > > 1) usb3.0 does not work at 9.1 and HEAD (r246587) > > > 2) Between stable/9 and HEAD (r246587) we are lost uhid devices > > > (external keyboard and mouse) and umass. dmesg on the same hw can find > > > here: > > > > > > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt > > > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt > > > > > > pciconf: > > > > > > http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt > > > > > > any help would be greatly apprecated. > > > > Hi, > > > > This error is not directly USB related. It means probably that ACPI or > > the PCI subsystem is not finding an IRQ for the XHCI driver. This might > > be the reason USB is not working properly. > > > > xhci0: Could not allocate IRQ > > device_attach: xhci0 attach returned 6 > > It seems that apple firmware assumes that USB host controller driver > will use MSI. FreeBSD drivers tries to set up the legacy IRQ, and fails > because apple tables do not describe this set-up. Hi, Would someone be kind enough to provide a patch for that for sys/dev/usb/controller/xhci_pci.c ? I'm currently not in possession of such hardware. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On Sunday 10 February 2013 12:12:52 Poul-Henning Kamp wrote: > Content-Type: text/plain; charset=ISO-8859-1 > > > In message <201302101211.15818.hsela...@c2i.net>, Hans Petter Selasky writes: > >As long as you leave room for USB floppy disks working. > > As far as I know, they are just umass devices, right ? They share > no actual code with fdc.c ? Right. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
Poul-Henning Kamp wrote: I tried to read a floppy disk yesterday. When was the last time anybody tried that with a FreeBSD release ? Based on my brief experiments yesterday, 6.X is the last release where accessing floppy disks carry less than a 10% risk of a panic. Unless somebody fixes the fdc driver to work in -current, I intend to dust of my axe and cut it from the tree later this spring. Floppy drive support was removed from Freebsd around release 7.0 I think. Read the release-notes for 6.0, 7.0 and 8.0 to determine when it happened. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On 10/02/2013, at 22:14, Poul-Henning Kamp wrote: >> I've used it in 7.x to read install.cfg for a semi automated install process. >> >> I didn't see any panics, but then again install.cfg is a pretty small file. > > On 7.x I got consistent panics about bounce-buffers. Hmm strange, I am not sure I have requisite hardware at work any more, all of the suitable machines were shipped. In any case I am in no position to maintain FDC as I no longer user it as part of my install process. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: some usb troubles
On Sun, Feb 10, 2013 at 12:10:14PM +0100, Hans Petter Selasky wrote: > On Sunday 10 February 2013 12:03:36 Hans Petter Selasky wrote: > > On Saturday 09 February 2013 19:01:25 Chagin Dmitry wrote: > > > Hi all, > > > > > > trying to run macbookpro10,1 on HEAD: > > > > > > 1) usb3.0 does not work at 9.1 and HEAD (r246587) > > > 2) Between stable/9 and HEAD (r246587) we are lost uhid devices > > > (external keyboard and mouse) and umass. dmesg on the same hw can find > > > here: > > > > > > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt > > > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt > > > > > > pciconf: > > > > > > http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt > > > > > > any help would be greatly apprecated. > > > > Hi, > > > > This error is not directly USB related. It means probably that ACPI or the > > PCI subsystem is not finding an IRQ for the XHCI driver. This might be the > > reason USB is not working properly. > > > > xhci0: Could not allocate IRQ > > device_attach: xhci0 attach returned 6 > > > > Hi, > > ehci1: mem 0xc1c16800-0xc1c16bff irq > 22 at device 29.0 on pci0 > > The following sysctl might also be of interest: > > hw.usb.xhci.xhci_port_route > > It decides if a port is connected to the EHCI or XHCI. > dchagin# sysctl hw.usb.xhci.xhci_port_route hw.usb.xhci.xhci_port_route: 0 btw, this is not the worst problem, usb 2.0 not working at HEAD, against 9.1, where the same hw works fine. -- Have fun! chd pgp5pTFQkX2Cs.pgp Description: PGP signature
Re: Time to kill fdc ?
Content-Type: text/plain; charset=ISO-8859-1 In message <9edf355d-07f7-4315-b00e-b181c674d...@gsoft.com.au>, "Daniel O'Conno r" writes: >I've used it in 7.x to read install.cfg for a semi automated install process. > >I didn't see any panics, but then again install.cfg is a pretty small file. On 7.x I got consistent panics about bounce-buffers. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Time to kill fdc ?
On 10/02/2013, at 21:36, Poul-Henning Kamp wrote: > I tried to read a floppy disk yesterday. > > When was the last time anybody tried that with a FreeBSD release ? > > Based on my brief experiments yesterday, 6.X is the last release > where accessing floppy disks carry less than a 10% risk of a panic. > > Unless somebody fixes the fdc driver to work in -current, I intend > to dust of my axe and cut it from the tree later this spring. I've used it in 7.x to read install.cfg for a semi automated install process. I didn't see any panics, but then again install.cfg is a pretty small file. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: some usb troubles
On Sun, Feb 10, 2013 at 12:03:36PM +0100, Hans Petter Selasky wrote: > On Saturday 09 February 2013 19:01:25 Chagin Dmitry wrote: > > Hi all, > > > > trying to run macbookpro10,1 on HEAD: > > > > 1) usb3.0 does not work at 9.1 and HEAD (r246587) > > 2) Between stable/9 and HEAD (r246587) we are lost uhid devices > > (external keyboard and mouse) and umass. dmesg on the same hw can find > > here: > > > > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt > > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt > > > > pciconf: > > > > http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt > > > > any help would be greatly apprecated. > > Hi, > > This error is not directly USB related. It means probably that ACPI or the > PCI > subsystem is not finding an IRQ for the XHCI driver. This might be the reason > USB is not working properly. > > xhci0: Could not allocate IRQ > device_attach: xhci0 attach returned 6 It seems that apple firmware assumes that USB host controller driver will use MSI. FreeBSD drivers tries to set up the legacy IRQ, and fails because apple tables do not describe this set-up. pgpRUZtgcavYB.pgp Description: PGP signature
Re: Time to kill fdc ?
Content-Type: text/plain; charset=ISO-8859-1 In message <201302101211.15818.hsela...@c2i.net>, Hans Petter Selasky writes: >As long as you leave room for USB floppy disks working. As far as I know, they are just umass devices, right ? They share no actual code with fdc.c ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Cross-architecture package installs
On Wed, Feb 06, 2013 at 06:20:22AM -0700, Ian Lepore wrote: > On Tue, 2013-02-05 at 22:34 -0800, Tim Kientzle wrote: > > I'm working on tools to build ARM system images. > > Usually, these tools run on x86, which creates a problem > > for packages. > > > > I would like to install packages onto the image as it's built. > > So I've been experimenting with variations of > >pkg -c add > > > > I'm running into a few problems but I think they can all be > > solved. Only the first is critical; the rest are relatively > > minor annoyances. > > > > 1) Pre-install/post-install scripts. > > > > These obviously don't work since the DESTDIR > > is for a different architecture. > > > > At least for post-install, it should be possible to > > record which packages still need their post-install > > scripts run and arrange to run them after first > > boot. I'm picturing an rc.d script that invokes pkg > > with appropriate options to find all packages > > that still need their post-install run and runs them. > > > > This won't work for pre-install, but those are rarer > > and we can hopefully work around them on a > > case-by-case basis. > > > > 2) The chroot happens before opening the package files. > > > > It's possible to work around this by copying all of the > > package files into DESTDIR first, but that's both > > time-consuming and rather awkward. (And quite > > tricky if you're installing directly onto a mounted > > image that has very little free space.) > > > > It should be feasible to open the package files first > > and then chroot. Then the actual installation still > > happens entirely inside DESTDIR. > > > > If you have a directory full of the package files, you can nullfs-mount > it within the chroot rather than copying its contents in. Nullfs mounts > are great for crossing chroot barriers in such situations. > > Using them does make your scripts more complex, because you need abort > and exit handling in the scripts to undo the mounts no matter what kind > of exit the script encounters. If you don't, you end up leaving nullfs > mounts that make later things fail (such as running the script again, or > trying to clean/remove a chroot tree). I'd rather avoid nullfs since it requires root or at least enabling user mounts. If one wanted to avoid opening all packages to start off, just opening the package directory and using dirfd() and openat() to do opens later could also work. Without looking at the pkg code it might require fewer changes to the existing code flow. -- Brooks pgpDOAFZTRUbP.pgp Description: PGP signature
Re: Time to kill fdc ?
On Sunday 10 February 2013 12:06:44 Poul-Henning Kamp wrote: > I tried to read a floppy disk yesterday. > > When was the last time anybody tried that with a FreeBSD release ? > > Based on my brief experiments yesterday, 6.X is the last release > where accessing floppy disks carry less than a 10% risk of a panic. > > Unless somebody fixes the fdc driver to work in -current, I intend > to dust of my axe and cut it from the tree later this spring. As long as you leave room for USB floppy disks working. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: some usb troubles
On Sunday 10 February 2013 12:03:36 Hans Petter Selasky wrote: > On Saturday 09 February 2013 19:01:25 Chagin Dmitry wrote: > > Hi all, > > > > trying to run macbookpro10,1 on HEAD: > > > > 1) usb3.0 does not work at 9.1 and HEAD (r246587) > > 2) Between stable/9 and HEAD (r246587) we are lost uhid devices > > (external keyboard and mouse) and umass. dmesg on the same hw can find > > here: > > > > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt > > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt > > > > pciconf: > > > > http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt > > > > any help would be greatly apprecated. > > Hi, > > This error is not directly USB related. It means probably that ACPI or the > PCI subsystem is not finding an IRQ for the XHCI driver. This might be the > reason USB is not working properly. > > xhci0: Could not allocate IRQ > device_attach: xhci0 attach returned 6 > Hi, ehci1: mem 0xc1c16800-0xc1c16bff irq 22 at device 29.0 on pci0 The following sysctl might also be of interest: hw.usb.xhci.xhci_port_route It decides if a port is connected to the EHCI or XHCI. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: some usb troubles
On Saturday 09 February 2013 19:01:25 Chagin Dmitry wrote: > Hi all, > > trying to run macbookpro10,1 on HEAD: > > 1) usb3.0 does not work at 9.1 and HEAD (r246587) > 2) Between stable/9 and HEAD (r246587) we are lost uhid devices > (external keyboard and mouse) and umass. dmesg on the same hw can find > here: > > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt > http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt > > pciconf: > > http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt > > any help would be greatly apprecated. Hi, This error is not directly USB related. It means probably that ACPI or the PCI subsystem is not finding an IRQ for the XHCI driver. This might be the reason USB is not working properly. xhci0: Could not allocate IRQ device_attach: xhci0 attach returned 6 --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Time to kill fdc ?
I tried to read a floppy disk yesterday. When was the last time anybody tried that with a FreeBSD release ? Based on my brief experiments yesterday, 6.X is the last release where accessing floppy disks carry less than a 10% risk of a panic. Unless somebody fixes the fdc driver to work in -current, I intend to dust of my axe and cut it from the tree later this spring. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CLANG and -fstack-protector
On Thu, Feb 07, 2013 at 11:52:42PM +0100, Jeremie Le Hen wrote: > You can do this, it will work for most of the ports but some ports do > not honor CFLAGS. Ports that don't honor CFLAGS are broken ports. Having said that, the last time I ran a script that looked for them (and other things like CXXFLAGS), the results were really disappointing. This would be a good project for someone to take on. OTOH this reply is probably more appropriate for ports@. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
