puc, ppc and MosChip SemiConductors Nm9805 Parallel Port Adapter
Hi, I've got an amd64 box with 1 built-in parallel port, which works fine. I also bought an add-on parallel port adapter card (a MosChip SemiConductors Nm9805 chip). After discovering puc, I enabled device puc and the card is now detected by puc, but doesn't appear to be picked up by the ppc driver. I'm running -STABLE from about 24 hours ago. In dmesg: puc0: port 0xd000-0xd00f,0xd400-0xd407,0xd800-0xd807, 0xdc00-0xdc07,0xe000-0xe007,0xe400-0xe407 irq 19 at device 8.0 on pci0 puc: name: NetMos NM9805 1284 Printer port puc0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xe400 port rid 16 bst 0, start e400, end e407 puc: Using ppc0 puc: type 2, bar 10, offset 0 In pciconf -lv: [EMAIL PROTECTED]:8:0: class=0x078000 card=0x00101000 chip=0x98059710 rev=0x01 hdr=0x00 vendor = 'MosChip Semiconductors (Was: Netmos Technology)' device = 'Nm9805 Parallel Port Adapter' class= simple comms However, despite the 'using ppc0' line, ppc0 is never mentioned again. The on-board parallel port is allocated to ppc1: ppc1: port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc1: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc1: FIFO with 16/16/9 bytes threshold ppbus0: on ppc1 ppbus0: IEEE1284 device found /NIBBLE/ECP Probing for PnP devices on ppbus0: ppbus0: MLC,PCL,PML lpt0: on ppbus0 lpt0: Interrupt-driven port However, ppc doesnt appear to exist: # sysctl dev.ppc.0 sysctl: unknown oid 'dev.ppc.0' Since the card is detected, and the puc driver claims to be 'using ppc0', I'm not really sure what to try now. Any one have any ideas? P.S. Please CC me on any replies, as I am not subscribed to this list. -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] puc/ppc and amd64
On Thu, 07 Apr 2005, David Taylor wrote: > Hi, > > I've got an amd64 box with 1 built-in parallel port, which works fine. > > I also bought an add-on parallel port adapter card (a MosChip > SemiConductors Nm9805 chip). After discovering puc, I enabled > device puc and the card is now detected by puc, but doesn't > appear to be picked up by the ppc driver. I have now, finally, figured out what was going on. After much wasted time trying to debug ppc_puc.c, I realised it wasn't even being compiled in the kernel. After adding dev/ppc/ppc_puc.c to files.amd64, everything worked a lot better. A patch (against 5-STABLE) is attached, which adds ppc_puc.c to all architectures with ppc.c listed (alpha, amd64, ia64 -- I can only test amd64, however). If this gets lost for ages, I'll add a PR... -- David Taylor --- sys/conf/files.alpha.oldWed Apr 13 12:20:57 2005 +++ sys/conf/files.alphaWed Apr 13 12:21:43 2005 @@ -183,6 +183,7 @@ dev/kbd/kbd.c optionalsc dev/kbd/kbd.c optionalukbd dev/ppc/ppc.c optionalppc +dev/ppc/ppc_puc.c optionalppc puc pci dev/sio/sio.c optionalsio dev/sio/sio_isa.c optionalsio isa dev/syscons/schistory.coptionalsc --- sys/conf/files.amd64.oldWed Apr 13 12:21:15 2005 +++ sys/conf/files.amd64Wed Apr 13 12:21:53 2005 @@ -133,6 +133,7 @@ dev/kbd/kbd.c optionalukbd dev/mem/memutil.c optionalmem dev/ppc/ppc.c optionalppc +dev/ppc/ppc_puc.c optionalppc puc pci dev/sio/sio.c optionalsio dev/sio/sio_isa.c optionalsio isa dev/syscons/apm/apm_saver.coptionalapm_saver apm --- sys/conf/files.ia64.old Wed Apr 13 12:21:05 2005 +++ sys/conf/files.ia64 Wed Apr 13 12:22:11 2005 @@ -59,6 +59,7 @@ dev/kbd/kbd.c optionalsc dev/kbd/kbd.c optionalukbd dev/ppc/ppc.c optionalppc isa +dev/ppc/ppc_puc.c optionalppc puc pci dev/syscons/schistory.coptionalsc dev/syscons/scmouse.c optionalsc dev/syscons/scterm-dumb.c optionalsc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dangerous situation with shutdown process
On Fri, 15 Jul 2005, Matthias Buelow wrote: > John-Mark Gurney wrote: > > >even request barries will not save the fs in a power loss if the track > >that is getting flushed durning a power loss... Some other FreeBSD > >folk has a reproducable case of where blocks that were not written to > >on ATA hardware got trashed after a power loss... > >With non-written to sectors getting trashed with the cache enabled, > >barriers don't mean squat... > > One more thought.. they _do_ protect against power loss during writing > a track -- when used in combination with a journalled fs. > > A corrupted journal can be detected. If it's corrupted, discard > the whole thing, or only the relevant entry. The filesystem will > remain consistent. > If track corruption occurs after the journal is written, it doesn't > matter, since at boot the journal will be replayed and all operations > will be performed once more. The track which is corrupted could contain data that wasn't written to in months. How would the journal help? > The combination barriers+journal really seems to be very resilient > to filesystem corruption. When it's implemented without errors, and > the hardware doesn't do things like change bits randomly, I can't > think of a way this scheme can be corrupted at all. I still don't trust ATA drives. Can you guarantee (or show any reason to believe) that disabling the write cache will actually wait for the cache to be flushed before returning? Otherwise a sequence is exactly the same as a command. If the drive executes both immediately, without waiting for the cache to be flushed _before_ returning, what's the difference? -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dangerous situation with shutdown process
On Sat, 16 Jul 2005, Matthias Buelow wrote: > David Taylor <[EMAIL PROTECTED]> writes: > > >> A corrupted journal can be detected. If it's corrupted, discard > >> the whole thing, or only the relevant entry. The filesystem will > >> remain consistent. > >> If track corruption occurs after the journal is written, it doesn't > >> matter, since at boot the journal will be replayed and all operations > >> will be performed once more. > > > >The track which is corrupted could contain data that wasn't written > >to in months. How would the journal help? > > I don't understand this question. When the drive is powered off, the track being written to at that point may be corrupted, right? That track may contain sectors that the OS did't change. These sectors would not be mentioned in the journal. How would a journaling fs fix the corruption? I suppose this could be avoided by requiring that all writes (and journal entries) somehow correspond to a full track. (Which I suppose they may do already, but I don't think so). > >I still don't trust ATA drives. Can you guarantee (or show any > >reason to believe) that disabling the write cache will actually > >wait for the cache to be flushed before returning? > >Otherwise a sequence is exactly > >the same as a command. If the drive executes > >both immediately, without waiting for the cache to be > >flushed _before_ returning, what's the difference? > > You imply that, because there exists one drive for which it doesn't > work, that it follows that it won't work for all drives? Or what is your > point? No. I'm just asking if you know of ANY ata drives that will wait for the cache to be flushed before claiming the disable cache command has succeeded. I don't, but I haven't looked. -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
4.3-BETA crash on 'mount /dev/acd0c /mnt'
(using: 4.3-BETA FreeBSD 4.3-BETA #3: Tue Mar 6 18:39:44 GMT 2001)
mount -t cd9660 /dev/acd0c /mnt #works ok
OTOH,
mount /dev/acd0c /mnt
causes the following panic:
IdlePTD 3657728
initial pcb at 2e2a00
panicstr: vm_fault: fault on nofault entry, addr: c7c11000
panic messages:
---
panic: vm_fault: fault on nofault entry, addr: c7c11000
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:469
#1 0xc014af55 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:309
#2 0xc014b2ed in panic (
fmt=0xc027a080 "vm_fault: fault on nofault entry, addr: %lx")
at /usr/src/sys/kern/kern_shutdown.c:556
#3 0xc01e39c6 in vm_fault (map=0xc02eb30c, vaddr=3357331456,
fault_type=3 '\003', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:240
#4 0xc0247602 in trap_pfault (frame=0xcd718f10, usermode=0, eva=3357331456)
at /usr/src/sys/i386/i386/trap.c:833
#5 0xc02471ef in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = -1072365552,
tf_edi = -937635840, tf_esi = 2352, tf_ebp = -848195744,
tf_isp = -848195780, tf_ebx = -1054105728, tf_edx = 368, tf_ecx = 304,
tf_eax = -1058161152, tf_trapno = 12, tf_err = 2,
tf_eip = -1071495692, tf_cs = 8, tf_eflags = 2163202,
tf_esp = -1054105728, tf_ss = -1057923520}) at
at /usr/src/sys/i386/i386/trap.c:443
#6 0xc02245f4 in atapi_read (request=0xc12b9f80, length=2352)
at machine/cpufunc.h:222
#7 0xc02240b2 in atapi_interrupt (request=0xc12b9f80)
at /usr/src/sys/dev/ata/atapi-all.c:385
#8 0xc021dae1 in ata_intr (data=0xc0edbe00)
at /usr/src/sys/dev/ata/ata-all.c:1150
also:
#6 0xc02245f4 in atapi_read (request=0xc148b480, length=2352)
at machine/cpufunc.h:222
#7 0xc02240b2 in atapi_interrupt (request=0xc148b480)
at /usr/src/sys/dev/ata/atapi-all.c:385
#8 0xc021dae1 in ata_intr (data=0xc0edbe00)
at /usr/src/sys/dev/ata/ata-all.c:1150
and:
#12 0xc02245f4 in atapi_read (request=0xc122d380, length=2352)
at machine/cpufunc.h:222
#13 0xc02240b2 in atapi_interrupt (request=0xc122d380)
at /usr/src/sys/dev/ata/atapi-all.c:385
#14 0xc021dae1 in ata_intr (data=0xc0edbe00)
at /usr/src/sys/dev/ata/ata-all.c:1150
When I was originally trying to mount a CD-RW disk, I also saw messages
like:
"kernel: ata1-master: too many segments in DMA table"
I'm not sure if that's because it was a CD-RW which FreeBSD didn't
understand, or if it's related to the bug that caused the panic..
'acd0: READ_CD commmand timeout - resetting' appeared just before the dump.
--
David Taylor
[EMAIL PROTECTED]
PGP signature
Re: Administrative tag a possibility?
Uh, please don't use BCC to send to the list, it makes replying a tad impossible. On Thu, 17 May 2001, Jamie Norwood wrote: > On Thu, May 17, 2001 at 07:43:27AM -0500, Stephen Montgomery-Smith wrote: > > > > That seems a little dangerous - perhaps some of the files will have > > md5 appearing in other lines for other reasons, and that would mess > > up this simple grep. Perhaps a more complicated tag in the file would > > be more appropriate. > > Not to mention that, AFAIK, once you add the checksum to the file, the > checksum would be different because the file is no longer the same, ne? > I am not aware of a way to include a checksum in the file being checked. There was a method in the message you quoted: - # Some config file # $FreeBSD: blah$ # $MD5-Checksum: abcdefg8273912$ # Foo a=1 b=2 - # (this is a Perl regexp, but it's possible with grep, somehow, I'm sure. CHECKSUM=`grep -v \$MD5-Checksum(: [0-9a-fA-F]*)?\$$ | md5` and it's easy enough to use sed to replace $MD5-Checksum$ lines with CHECKSUM, and also compare the two... CVS could even be setup to automagically insert the checksum, as it does with the $FreeBSD$ lines currently.. (Doing so whilst observing the various weird -ki flags to disable $$ expansions would be more difficult, however). -- David Taylor [EMAIL PROTECTED] PGP signature
Re: Possible Install bug for the following hardware in FreeBSD Stable (4.3)
On Wed, 30 May 2001, Darian Lanx wrote: > Hello list. > After debugging this with a few friends who are by far more experience din > freebsd than I am, I have been asked to report the following strange > behaviour to this list > > He asked me to be specific, so I am going to provide a much information as I > can. > The hardware used is as follows: > ASUS CUSL Motherboard > 2 Hard drives > On the primary Master a Maxtor 53073U6 30736 MB > ioctl (I am in linux) reports the following > geometry for it: > geometry = 3736/255/63, sectors = 60030432, start = 0 > > The second hard drive on the secondary Master channel is a IBM DTLA-307030 > also 30736 MB. ioctl reports the following geometry for this drive: > geometry = 3737/255/63, sectors = 60036480, start = 0 > > I have downloaded the 4.3 boot floppies from ftp.at.freebsd.org and then > booted my system. > After entering the installer friend told me to press scroll lock and scroll > up to see the actual output of the Kernel. > > The output for the drives reads as follows: > ad0 2014 MB [4092/16/63] at at-0-master UDMA66 I had this problem after I enabled the '4092-cylinder limit' jumper on my Maxtor drive, because my BIOS (at that point) hung with a drive over 4092 cylinders. I flashed the BIOS afterwards, but forgot about the jumper, because windows/linux both (somehow) saw the full geometry of the drive. FreeBSD only saw 2014MB until I removed the jumper. Perhaps your drive has a similar jumper? check the manual. > ad2 29314 MB [5956/16/63 at at-1-master UDMA100 29314 * 1024 * 1024 bytes (i.e. 2914 megabytes) == 30736 * 1000 * 1000 bytes (i.e. 2914 million bytes) Its something harddrive manufacturers do to make their drives look bigger... -- David Taylor [EMAIL PROTECTED] PGP signature
Re: Upgrading from FreeBSD 5.4 to 5.5 STABLE
On Sat, 2007-11-17 at 14:02 -0500, Nic Reveles wrote: > "Clifton Royston" wrote: > > On Sat, Nov 17, 2007 at 12:21:25PM -0500, Nic Reveles wrote: > >> Thanks for the tips! Still having the same problem though... > >> > >> I have changed the tag in my supfile to: > >> *default tag=RELENG_5_5 > >> > >> I then removed the directory '/usr/src/contrib/cvs' and ran cvsup again. > >> > >> But when I run 'make buildworld' I still get the previous error. > > > > Did you try removing any CFLAGS settings from /etc/make.conf? > I've checked /etc/make.conf and there are no CFLAGs in it. I've never > changed it since I started using the computer, but here is what I did find: > > > # added by use.perl 2005-09-05 11:07:59 > PERL_VER=5.8.6 > PERL_VERSION=5.8.6 > > The error message I'm recieving makes reference to Perl, is it possible that > the syntax of Perl changed and I need to update it and this make.conf file? Please don't top post, it makes the thread impossible to follow The PERL_* stuff is for ports, it is highly unlikely to affect your buildworld. The error message itself isn't really referring to perl, the command prior to the error (which seems to have completed relatively successfully) is. Immediately after the error occurs, what are the contents of /usr/src/gnu/usr.bin/cvs/contrib/Makefile and /usr/src/contrib/cvs/contrib/Makefile ? (specifically what is around line 15?) David -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] 7-STABLE Build broken in geom_io.c with KTR but no DDB
Hi,
I've been trying to do some debugging with ktrace(9) for the first time,
and ran in to a problem after trying to compile the kernel.
I didn't have DDB defined, and as a result the build failed
after adding "option KTR":
geom_io.o(.text+0x5ee): In function `g_alloc_bio':
../../../geom/geom_io.c:140: undefined reference to `stack_save'
geom_io.o(.text+0x61e):../../../geom/geom_io.c:141: undefined reference to
`stack_ktr'
geom_io.o(.text+0x6e1): In function `g_clone_bio':
The use of CTRx in the geom code appears to be correctly wrapped with
#ifdef KTR, but this is also all that protects the uses of CTRSTACK.
CTRSTACK is also defined to use stack_ktr conditionally on #ifdef KTR in
sys/stack.h, but the stack_ktr function is compiled in to the kernel only
if DDB is enabled.
Perhaps CTRSTACK should be non-empty only if both DDB and KTR are defined?
--
David Taylor
Index: sys/stack.h
===
RCS file: /home/ncvs/src/sys/sys/stack.h,v
retrieving revision 1.2
diff -u -r1.2 stack.h
--- sys/stack.h 29 Aug 2005 11:34:08 - 1.2
+++ sys/stack.h 31 Dec 2007 19:14:10 -
@@ -46,7 +46,7 @@
void stack_zero(struct stack *);
void stack_print(struct stack *);
void stack_sbuf_print(struct sbuf *, struct stack *);
-#ifdef KTR
+#if defined(DDB) && defined(KTR)
void stack_ktr(u_int, const char *, int, struct stack *, u_int, int);
#define CTRSTACK(m, st, depth, cheap) do {\
if (KTR_COMPILE & (m)) \
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] 7-STABLE Build broken in geom_io.c with KTR but no DDB
On Mon, 31 Dec 2007, David Taylor wrote: > Hi, > > I've been trying to do some debugging with ktrace(9) for the first time, > and ran in to a problem after trying to compile the kernel. > > I didn't have DDB defined, and as a result the build failed > after adding "option KTR": > > geom_io.o(.text+0x5ee): In function `g_alloc_bio': > ../../../geom/geom_io.c:140: undefined reference to `stack_save' > geom_io.o(.text+0x61e):../../../geom/geom_io.c:141: undefined reference to > `stack_ktr' > geom_io.o(.text+0x6e1): In function `g_clone_bio': > > The use of CTRx in the geom code appears to be correctly wrapped with > #ifdef KTR, but this is also all that protects the uses of CTRSTACK. > > CTRSTACK is also defined to use stack_ktr conditionally on #ifdef KTR in > sys/stack.h, but the stack_ktr function is compiled in to the kernel only > if DDB is enabled. > > Perhaps CTRSTACK should be non-empty only if both DDB and KTR are defined? OK, the attached patch is necessary, but not quite sufficient to fix the problem. geom_io.c also calls stack_save() under #ifdef KTR, when it needs to be under an #ifdef DDB as well... P.S. Happy New Year everyone! -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: win32-codecs question ...
On Thu, 04 Jan 2007, David Syphers wrote: > On Thursday 04 January 2007 13:39, Freddie Cash wrote: > > If a port supports the OPTION framework, then the first time you run make [snip] > > And a mention of it in /usr/ports/UPDATING > > and/or /usr/ports/CHANGES. > > Now, this I read. And no, it's not documented there. The only mentions in > UPDATING are under postfix entries, and I don't use postfix. The entries in > CHANGES wouldn't catch your eye unless you knew what you were looking for - > everything assumes prior knowledge of what OPTIONS is and what it implies. The third entry in CHANGES mentions it in passing. It appears to have been introduced before the CHANGES file started. -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 7 and java networking
Hello, I'm having terrible problems getting java working properly on FreeBSD-7. I've tried java/diablo-jdk15 -- this doesn't work very well at all. It coredumps running azureus and behaves very oddly running jbidwatcher (my two current "test applications"). java/linux-sun-jdk15 and java/linux-sun-jdk16 do work with jbidwatcher. In fact it seems to be fine (I had some problem with _all_ the jdks disliking a MAXDSIZ greater than 900MB). However, azureus cannot be compiled (or run) against a non-native jdk, so I need to compile my own... I've tried compiling java/jdk15 and java/jdk16 bootstrapping with all three binary jdks (diablo 1.5, linux 1.5, linux 1.6). They all give the same problem: Running jbidwatcher or azureus results in a mass of messages like the following, whenever network IO is attempted: java.net.ConnectException: Invalid argument at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1223) at java.security.AccessController.doPrivileged(Native Method) at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1217) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:906) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234) at Http.receiveData(Unknown Source) at Http.receivePage(Unknown Source) at ebayServer.getSignInCookie(Unknown Source) at ebayServer.getSignInCookie(Unknown Source) at ebayServer.getNecessaryCookie(Unknown Source) at ebayServer.messageAction(Unknown Source) at PlainMessageQueue.run(Unknown Source) at java.lang.Thread.run(Thread.java:595) Caused by: java.net.ConnectException: Invalid argument at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.Socket.connect(Socket.java:520) at sun.net.NetworkClient.doConnect(NetworkClient.java:155) at sun.net.www.http.HttpClient.openServer(HttpClient.java:387) at sun.net.www.http.HttpClient.openServer(HttpClient.java:522) at sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:278) at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:335) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:765) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:934) at sun.net.www.protocol.http.HttpURLConnection.getHeaderFieldKey(HttpURLConnection.java:1956) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getHeaderFieldKey(HttpsURLConnectionImpl.java:287) at CookieJar.getAllCookiesFromPage(Unknown Source) at CookieJar.getAllCookiesFromPage(Unknown Source) ... 6 more I've put the full output of jbidwatcher at: http://www.yadt.co.uk/~davidt/java/jbidwatcher.out There is also: http://www.yadt.co.uk/~davidt/java/ifconfig.out http://www.yadt.co.uk/~davidt/java/dmesg.out http://www.yadt.co.uk/~davidt/java/make.conf http://www.yadt.co.uk/~davidt/java/kernel-config http://www.yadt.co.uk/~davidt/java/loader.conf If anyone has _any_ ideas (or needs any other information), please let me know... This is driving me nuts! I briefly tried writing a small java testcase to trigger the problem, but my java is rusty and I ran out of time and patience -- my extremely brief test seemed to work ok and I started to think it may be related to multi-threading... If I can't fix it any other way, I'll give it another shot. -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 7 and java networking
On Thu, 08 Nov 2007, Peter Wullinger wrote: > 2007/11/7, Peter Wullinger <[EMAIL PROTECTED]>: > > > > In epistula a David Taylor, die horaque Wed, Nov 07, 2007 at 06:18:57PM > > +: > > > Hello, > > > > > > I've tried compiling java/jdk15 and java/jdk16 bootstrapping with > > > all three binary jdks (diablo 1.5, linux 1.5, linux 1.6). > > > > > > They all give the same problem: > > > > Hello David, > > > > Have you tried setting > > > > export JAVAVAVM_OPTS_java=-Djava.net.preferIPv4Stack=true" > > export JAVAVAVM_OPTS_javaws="-J-Djava.net.preferIPv4Stack=true" > > > of course this has to be JAVAVM_OPTS_java and JAVAVM_OPTS_javawm .. Thanks! This does indeed fix the problem. Is there any more information on the problem with IPv6? -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATA RAID problem in 6.0-RC1 (ata_alloc_request/ata_raid_init_request)
I've been seeing a number of strange messages in my log since updating to 6.0-RC1. Usually they happen when some intense disk access is happening (e.g. when /etc/periodic/security/100.chksetuid is running at 03:01), but it doesn't happen _every_ morning, and it doesn't always happen if I manually run the script. It also occasionally happens at times where I wouldn't say I was doing much with the disk. I'm hoping nothing bad is happening to my data. At least, fsck doesn't mention any problems, and I haven't noticed any corruption yet... I'm on an AMD64 system, with an MSI K8T-Neo2 motherboard. ATA-related dmesg: Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-RC1 #0: Wed Oct 12 21:05:06 BST 2005 [EMAIL PROTECTED]:/usr/obj/repo/FreeBSD/FreeBSD-6.x/src/sys/OUTCOLD ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3500+ (2200.10-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 Features=0x78bfbff AMD Features=0xe2500800,LM,3DNow+,3DNow> real memory = 1073676288 (1023 MB) avail memory = 1027952640 (980 MB) ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) ... atapci0: port 0xec00-0xec7f,0xe800-0xe8ff mem 0xcfffb000-0xcfffbfff,0xcffc-0xcffd irq 17 at device 13.0 on pci0 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 atapci1: port 0xc800-0xc807,0xc400-0xc403,0xc000-0xc007,0xbc00-0xbc03,0xb800-0xb80f,0xb400-0xb4ff irq 20 at device 15.0 on pci0 ata5: on atapci1 ata6: on atapci1 atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: on atapci2 ata1: on atapci2 ... ad0: 32634MB at ata0-master UDMA66 acd0: DVDR at ata1-master UDMA33 ad4: 156334MB at ata2-master SATA150 ad6: 156334MB at ata3-master SATA150 ar0: 156334MB status: READY ar0: disk0 READY (master) using ad6 at ata3-master ar0: disk1 READY (mirror) using ad4 at ata2-master atacontrol output: # atacontrol list ATA channel 0: Master: ad0 ATA/ATAPI revision 4 Slave: no device present ATA channel 1: Master: acd0 ATA/ATAPI revision 0 Slave: no device present ATA channel 2: Master: ad4 Serial ATA v1.0 Slave: no device present ATA channel 3: Master: ad6 Serial ATA v1.0 Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present ATA channel 6: Master: no device present Slave: no device present # atacontrol status ar0 ar0: ATA RAID1 subdisks: ad6 ad4 status: READY A sample of the error messages follows: Oct 25 21:20:21 outcold kernel: DOH! ata_alloc_request failed! Oct 25 21:20:23 outcold kernel: FAILURE - out of memory in ata_raid_init_request Oct 25 21:20:23 outcold last message repeated 131 times Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34597617664, length=16384)]error = 5 Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34597748736, length=16384)]error = 5 Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34597961728, length=16384)]error = 5 Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34598207488, length=16384)]error = 5 Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34598453248, length=16384)]error = 5 Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34598682624, length=16384)]error = 5 Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34598895616, length=16384)]error = 5 Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34599174144, length=16384)]error = 5 Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34599452672, length=16384)]error = 5 Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34599747584, length=16384)]error = 5 ... ... Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34629107712, length=16384)]error = 5 Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34629386240, length=16384)]error = 5 Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34629648384, length=16384)]error = 5 Oct 25 21:20:53 outcold kernel: DOH! ata_alloc_request failed! Oct 25 21:20:53 outcold kernel: FAILURE - out of memory in ata_raid_init_request Oct 25 21:20:53 outcold last message repeated 146 times Oct 25 21:20:53 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=7635156992, length=16384)]error = 5 Oct 25 21:20:53 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=7635533824, length=16384)]error = 5 Oct 25 21:20:53 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=7635992576, length=16384)]error = 5 ... ... etc If y
Re: ATA RAID problem in 6.0-RC1 (ata_alloc_request/ata_raid_init_request)
On Wed, 26 Oct 2005, David Taylor wrote: > I've been seeing a number of strange messages in my log since > updating to 6.0-RC1. Usually they happen when some intense > disk access is happening (e.g. when /etc/periodic/security/100.chksetuid > is running at 03:01), but it doesn't happen _every_ morning, and > it doesn't always happen if I manually run the script. > It also occasionally happens at times where I wouldn't say I was doing > much with the disk. [snip] I'm still seeing (lots) of these messages (below) on 6.0-RELEASE. Should I just file a PR about it, and is there anything else that would be useful to track down what's causing them? > A sample of the error messages follows: > > Oct 25 21:20:21 outcold kernel: DOH! ata_alloc_request failed! > Oct 25 21:20:23 outcold kernel: FAILURE - out of memory in > ata_raid_init_request > Oct 25 21:20:23 outcold last message repeated 131 times > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34597617664, > length=16384)]error = 5 > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34597748736, > length=16384)]error = 5 > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34597961728, > length=16384)]error = 5 > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34598207488, > length=16384)]error = 5 > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34598453248, > length=16384)]error = 5 > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34598682624, > length=16384)]error = 5 > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34598895616, > length=16384)]error = 5 > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34599174144, > length=16384)]error = 5 > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34599452672, > length=16384)]error = 5 > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34599747584, > length=16384)]error = 5 > ... > ... > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34629107712, > length=16384)]error = 5 > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34629386240, > length=16384)]error = 5 > Oct 25 21:20:23 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=34629648384, > length=16384)]error = 5 > Oct 25 21:20:53 outcold kernel: DOH! ata_alloc_request failed! > Oct 25 21:20:53 outcold kernel: FAILURE - out of memory in > ata_raid_init_request > Oct 25 21:20:53 outcold last message repeated 146 times > Oct 25 21:20:53 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=7635156992, > length=16384)]error = 5 > Oct 25 21:20:53 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=7635533824, > length=16384)]error = 5 > Oct 25 21:20:53 outcold kernel: g_vfs_done():ar0s1f[WRITE(offset=7635992576, > length=16384)]error = 5 > ... > ... > etc -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA RAID problem in 6.0-RC1 (ata_alloc_request/ata_raid_init_request)
On Thu, 10 Nov 2005, Michael Butler wrote: > David Taylor wrote: > > | [snip] > | > | I'm still seeing (lots) of these messages (below) on 6.0-RELEASE. > | Should I just file a PR about it, and is there anything else that > | would be useful to track down what's causing them? > > I get these with an HighPoint HPT372N UDMA133 controller .. what is your's? It was in my previous mail, perhaps I snipped a little too much... anyway: atapci0: port 0xec00-0xec7f,0xe800-0xe8ff mem 0xcfffb000-0xcfffbfff,0xcffc-0xcffd irq 17 at device 13.0 on pci0 atapci1: port 0xc800-0xc807,0xc400-0xc403,0xc000-0 xc007,0xbc00-0xbc03,0xb800-0xb80f,0xb400-0xb4ff irq 20 at device 15.0 on pci0 atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376, ar0 (mentioned in the error messages) is ad4 and ad6, which are connected to the Promise controller. ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 ad4: 156334MB at ata2-master SATA150 ad6: 156334MB at ata3-master SATA150 ar0: 156334MB status: READY ar0: disk0 READY (master) using ad6 at ata3-master ar0: disk1 READY (mirror) using ad4 at ata2-master -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Data Loss with samba shared USB drive
I have a USB drive (SanDisk 1GB flash drive), which I have mounted on a windows PC using samba 3.0. I recently discovered the copy of my files on my USB device were corrupted (thankfully I had a backup), being filled entirely with 0's (that's ASCII '0', not NUL). I have managed to reproduce the problem with these steps. 1. Mount USB drive on (say) /usb 2. Share /usb over samba 3. (Optional) On windows PC mount \\server\usb as (say) U: 4. Change something on /usb drive (from windows or freebsd) 5. On FreeBSD machine type "umount /usb" -- get "Device busy" error 6. View changed file. When I've tried this, it results in the contents of the modified file being entirly replaced by a string of 0. This only happens on a USB device, when samba is running. The share does not need to be mounted on the windows PC for this to occur. If anyone has any ideas, or wants any more information, please let me know. uname: FreeBSD outcold.yadt.co.uk 6.0-STABLE FreeBSD 6.0-STABLE #2: Wed Nov 9 14:14:34 GMT 2005 [EMAIL PROTECTED]:/usr/obj/repo/FreeBSD/FreeBSD-6.x/src/sys/ OUTCOLD amd64 usb drive attach dmesg: umass0: SanDisk Flash Disk, rev 1.10/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 1048576MB (2147484160 512 byte sectors: 255H 63S/T 133674C) samba version: samba-3.0.20b,1 A free SMB and CIFS client and server for UNIX -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Data Loss with samba shared USB drive
On Sat, 03 Dec 2005, David Taylor wrote: > I have a USB drive (SanDisk 1GB flash drive), which I have mounted > on a windows PC using samba 3.0. > > I recently discovered the copy of my files on my USB device were > corrupted (thankfully I had a backup), being filled entirely with > 0's (that's ASCII '0', not NUL). > > I have managed to reproduce the problem with these steps. > > 1. Mount USB drive on (say) /usb > 2. Share /usb over samba > 3. (Optional) On windows PC mount \\server\usb as (say) U: > 4. Change something on /usb drive (from windows or freebsd) > 5. On FreeBSD machine type "umount /usb" -- get "Device busy" error > 6. View changed file. I should probably mention that this is with the drive formatted with a FAT filesystem. -- David Taylor ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OpenSSH not updating
On Mon, 10 Dec 2001, Chris Faulhaber wrote: > On Tue, Dec 11, 2001 at 03:02:33PM +1100, Rob B wrote: > > > > ewps :) If I ran the patch again, answering N to the -R question, would > > this correct my goof? > > > > Yep. > Nope. patch won't ask the -R question, since the patch has not been previously applied :) -- David Taylor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
