Re: qlnxe driver not in 13.0 arm64
Daniel Morante via freebsd-stable wrote this message on Sun, Mar 28, 2021 at 03:23 -0400: > I installed 13.0-RC3 ARM64 from the DVD ISO image > (FreeBSD-13.0-BETA4-arm64-aarch64-dvd1.iso > <http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.0/FreeBSD-13.0-BETA4-arm64-aarch64-dvd1.iso>). > > There is no "if_qlnxe" kernel model present on the install media, or on > the system after installing. > > Next I try to build a custom kernel. I add "device qlnxe" to the > configuration file as instructed in > https://www.freebsd.org/cgi/man.cgi?query=qlnxe=FreeBSD+13.0-current. > > > Running "make buildkernel KERNCONF=THUNDERX2" results in: > > config: Error: device "qlnxe" is unknown > > Is this module not available for ARM64 architecture? Correct, this is only available for amd64. HPS might have some more insight as to why it's amd64 only. I have cc'd him. It could be as simple as moving the qlnxe lines from files.amd64 to files, but it does appear that qnlxe depends upon the Linux compat layer, which may not be complete for arm64.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Has geli broken when using authentication (hmac/sha256)?
Dewayne Geraghty wrote this message on Fri, Nov 06, 2020 at 16:46 +1100:
> Using FreeBSD 12.2S r367125M, to
> # geli init -a HMAC/SHA256 -e aes-cbc -l 128 -P -s 4096 -K /tmp/key ${D}s1a
> fails during newfs,
> # newfs -O2 -U ${D}s1a.eli
> newfs: can't read old UFS1 superblock: read error from block device:
> Invalid argument
>
> Using geli with encryption only, works as usual. But using hmac/sha256
> fails when used with "-e null" or in combination with a cipher.
>
> Using encryption only, everything is normal, ie newfs ok, the filesystem
> mounts and is accessible.
>
> Could someone verify if something is broken? I've included my test case
> below:
What happens if you zero out the device first:
dd if=/dev/zero of=${D}s1a.eli bs=1m
If it's large, you likely only need to set the count to 1 or 2...
newfs is likely trying to read make sure there aren't any old file
systems there, but geli init doesn't write new data, so any reads will
fail...
Note that the geli man page says:
It is recommended to write to the whole provider before first use, in
order to make sure that all sectors and their corresponding checksums are
properly initialized into a consistent state. One can safely ignore data
authentication errors that occur immediately after the first time a
provider is attached and before it is initialized in this way.
Also, are you sure this worked BEFORE the changes? Because those changes
shouldn't have caused this failure...
> openssl rand -hex -out /tmp/key 32
> geli init -a HMAC/SHA256 -e aes-cbc -l 128 -P -s 4096 -K /tmp/key ${D}s1a
> geli attach -p -k /tmp/key ${D}s1a
I don't see a write here...
> newfs -O2 -U ${D}s1a.eli
> /dev/md0s1a.eli: 8.9MB (18200 sectors) block size 32768, fragment size 4096
> using 4 cylinder groups of 2.25MB, 72 blks, 384 inodes.
> with soft updates
> newfs: can't read old UFS1 superblock: read error from block device:
> Invalid argument
>
> However using UFS1, newfs succeeds but the mount fails.
>
> newfs -O1 -U ${D}s1a.eli
> /dev/md0s1a.eli: 8.9MB (18200 sectors) block size 32768, fragment size 4096
> using 4 cylinder groups of 2.25MB, 72 blks, 512 inodes.
> with soft updates
> super-block backups (for fsck_ffs -b #) at:
> 64, 4672, 9280, 13888
> # mount -v /dev/md0s1a.eli /mnt/A
> mount: /dev/md0s1a.eli: Invalid argument
This is likely trying to read a UFS v2 super block, failing, and not
trying other locations...
> The only change that may be related is:
>
> # svnlite log -l 4 /usr/src/tests/sys/geom/class/eli
>
> r363486 | asomers | 2020-07-25 04:19:25 +1000 (Sat, 25 Jul 2020) | 13 lines
>
> MFC r363014:
>
> geli: enable direct dispatch
>
> geli does all of its crypto operations in a separate thread pool, so
> g_eli_start, g_eli_read_done, and g_eli_write_done don't actually do very
> much work. Enabling direct dispatch eliminates the g_up/g_down bottlenecks,
> doubling IOPs on my system. This change does not affect the thread pool.
>
> Reviewed by:markj
> Sponsored by: Axcient
> Differential Revision: https://reviews.freebsd.org/D25587
>
> Cheers, Dewayne
>
> --
> *** NOTICE This email and any attachments may contain legally privileged
> or confidential information and may be protected by copyright. You must
> not use or disclose them other than for the purposes for which they were
> supplied. The privilege or confidentiality attached to this message and
> attachments is not waived by reason of mistaken delivery to you. If you
> are not the intended recipient, you must not use, disclose, retain,
> forward or reproduce this message or any attachments. If you receive
> this message in error please notify the sender by return email or
> telephone and destroy and delete all copies. ***
> _______
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.2-RC1: RTL8251/8153 1000BASE-T seemingly stuck at 100Mbps
sreehari wrote this message on Thu, Oct 08, 2020 at 16:04 -0700: > ok I tried cherry picking the commit from head to stable/12 according to > one person's suggestion and I get some hunk failed's when i try patch -C > -p0. Is there any way I can simulate the MFC? Sorry I'm just not familiar > with svn Sorry, I missed this reply... I'll be merging the change into stable/12 in the comming week... > On Thu, Oct 8, 2020, 00:53 John-Mark Gurney wrote: > > > sreehari wrote this message on Wed, Oct 07, 2020 at 23:56 -0700: > > > I see. Since I have the hardware and freebsd head seems broken on my > > > laptop, I'll try compiling stable/12 with the ure patch from head within > > > the next few days. I have gigabit internet and other machines to test the > > > ethernet with the full 1000Mbps. Are there any actions you suggest I take > > > to benchmark or stress test the hardware or make sure everything is > > working > > > properly? > > > > Nothing in particular... iperf or iperf3 works well... do normal > > transfers and make sure you don't see packet drops that are unexpected > > (checksumming was enabled)... If you have vlans, use those... Just be > > aware of any unexpected behaviors.. > > > > Thanks for the additional testing! And letting mek now that it works > > is useful! > > > > > On Wed, Oct 7, 2020, 23:36 John-Mark Gurney wrote: > > > > > > > Kurt Jaeger wrote this message on Thu, Oct 08, 2020 at 06:36 +0200: > > > > > > sreehari wrote this message on Tue, Oct 06, 2020 at 21:02 -0700: > > > > > > > I have a USB C hub that supports gigabit ethernet under any > > other OS, > > > > > > > but under FreeBSD it seems to detect it properly, but I never get > > > > > > > speeds exceeding 100Mbps transfer rate on the whole thing. Is > > this a > > > > > > > known issue? Also is there any way to check what the perceived > > link > > > > > > > speed is? I've attached dmesg.boot if that helps. > > > > > > > > > > > > This is a known issue w/ the ure driver on FreeBSD. This has been > > > > > > fixed in -current, and in a few months I'll look at merging it to > > > > > > stable/12, but it definitly will not make the 12.2 release: > > > > > > https://reviews.freebsd.org/D25809 > > > > > > > > > > The changes seem to be limited to the driver itself -- is some > > > > > structural change in 13 stopping a merge to 12.2 ? > > > > > > > > The issue is that IMO, it's too close to the release of 12.2. It only > > > > recently got committed to 13, and so hasn't had enough time to be > > tested > > > > in more environments than mine. There have been a few others that have > > > > tested it. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.2-RC1: RTL8251/8153 1000BASE-T seemingly stuck at 100Mbps
sreehari wrote this message on Thu, Oct 08, 2020 at 00:06 -0700: > if there is more rigorous testing of the new code would it be possible for > the commit to make it into 12.2? A merge to 12.2 would be a question for re@ now... I have a feeling that they're too far along the release process to accept a change like this... I'll check, but I think I can commit the driver to stable/12 now, as the re process is working off releng/12.2... > On Wed, Oct 7, 2020, 23:56 sreehari wrote: > > > I see. Since I have the hardware and freebsd head seems broken on my > > laptop, I'll try compiling stable/12 with the ure patch from head within > > the next few days. I have gigabit internet and other machines to test the > > ethernet with the full 1000Mbps. Are there any actions you suggest I take > > to benchmark or stress test the hardware or make sure everything is working > > properly? > > > > On Wed, Oct 7, 2020, 23:36 John-Mark Gurney wrote: > > > >> Kurt Jaeger wrote this message on Thu, Oct 08, 2020 at 06:36 +0200: > >> > > sreehari wrote this message on Tue, Oct 06, 2020 at 21:02 -0700: > >> > > > I have a USB C hub that supports gigabit ethernet under any other > >> OS, > >> > > > but under FreeBSD it seems to detect it properly, but I never get > >> > > > speeds exceeding 100Mbps transfer rate on the whole thing. Is this a > >> > > > known issue? Also is there any way to check what the perceived link > >> > > > speed is? I've attached dmesg.boot if that helps. > >> > > > >> > > This is a known issue w/ the ure driver on FreeBSD. This has been > >> > > fixed in -current, and in a few months I'll look at merging it to > >> > > stable/12, but it definitly will not make the 12.2 release: > >> > > https://reviews.freebsd.org/D25809 > >> > > >> > The changes seem to be limited to the driver itself -- is some > >> > structural change in 13 stopping a merge to 12.2 ? > >> > >> The issue is that IMO, it's too close to the release of 12.2. It only > >> recently got committed to 13, and so hasn't had enough time to be tested > >> in more environments than mine. There have been a few others that have > >> tested it. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.2-RC1: RTL8251/8153 1000BASE-T seemingly stuck at 100Mbps
sreehari wrote this message on Wed, Oct 07, 2020 at 23:56 -0700: > I see. Since I have the hardware and freebsd head seems broken on my > laptop, I'll try compiling stable/12 with the ure patch from head within > the next few days. I have gigabit internet and other machines to test the > ethernet with the full 1000Mbps. Are there any actions you suggest I take > to benchmark or stress test the hardware or make sure everything is working > properly? Nothing in particular... iperf or iperf3 works well... do normal transfers and make sure you don't see packet drops that are unexpected (checksumming was enabled)... If you have vlans, use those... Just be aware of any unexpected behaviors.. Thanks for the additional testing! And letting mek now that it works is useful! > On Wed, Oct 7, 2020, 23:36 John-Mark Gurney wrote: > > > Kurt Jaeger wrote this message on Thu, Oct 08, 2020 at 06:36 +0200: > > > > sreehari wrote this message on Tue, Oct 06, 2020 at 21:02 -0700: > > > > > I have a USB C hub that supports gigabit ethernet under any other OS, > > > > > but under FreeBSD it seems to detect it properly, but I never get > > > > > speeds exceeding 100Mbps transfer rate on the whole thing. Is this a > > > > > known issue? Also is there any way to check what the perceived link > > > > > speed is? I've attached dmesg.boot if that helps. > > > > > > > > This is a known issue w/ the ure driver on FreeBSD. This has been > > > > fixed in -current, and in a few months I'll look at merging it to > > > > stable/12, but it definitly will not make the 12.2 release: > > > > https://reviews.freebsd.org/D25809 > > > > > > The changes seem to be limited to the driver itself -- is some > > > structural change in 13 stopping a merge to 12.2 ? > > > > The issue is that IMO, it's too close to the release of 12.2. It only > > recently got committed to 13, and so hasn't had enough time to be tested > > in more environments than mine. There have been a few others that have > > tested it. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.2-RC1: RTL8251/8153 1000BASE-T seemingly stuck at 100Mbps
Kurt Jaeger wrote this message on Thu, Oct 08, 2020 at 06:36 +0200: > > sreehari wrote this message on Tue, Oct 06, 2020 at 21:02 -0700: > > > I have a USB C hub that supports gigabit ethernet under any other OS, > > > but under FreeBSD it seems to detect it properly, but I never get > > > speeds exceeding 100Mbps transfer rate on the whole thing. Is this a > > > known issue? Also is there any way to check what the perceived link > > > speed is? I've attached dmesg.boot if that helps. > > > > This is a known issue w/ the ure driver on FreeBSD. This has been > > fixed in -current, and in a few months I'll look at merging it to > > stable/12, but it definitly will not make the 12.2 release: > > https://reviews.freebsd.org/D25809 > > The changes seem to be limited to the driver itself -- is some > structural change in 13 stopping a merge to 12.2 ? The issue is that IMO, it's too close to the release of 12.2. It only recently got committed to 13, and so hasn't had enough time to be tested in more environments than mine. There have been a few others that have tested it. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 12.2-RC1: RTL8251/8153 1000BASE-T seemingly stuck at 100Mbps
sreehari wrote this message on Tue, Oct 06, 2020 at 21:02 -0700: > I have a USB C hub that supports gigabit ethernet under any other OS, > but under FreeBSD it seems to detect it properly, but I never get > speeds exceeding 100Mbps transfer rate on the whole thing. Is this a > known issue? Also is there any way to check what the perceived link > speed is? I've attached dmesg.boot if that helps. This is a known issue w/ the ure driver on FreeBSD. This has been fixed in -current, and in a few months I'll look at merging it to stable/12, but it definitly will not make the 12.2 release: https://reviews.freebsd.org/D25809 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
CFT: update to if_ure driver
Hello, I have committed an update to the ure driver on the stable/11 branch. I don't have any 8152 devices to test with, so I'd greatly appreciate any feedback on if this works or doesn't work. Also, if you have a spare 8152 that you could part with and send to me, it'd make testing changes like these easier. On stable/11, 8153 devices are attached via the cdce devices, and so will not be affected by this change. - Forwarded message from John-Mark Gurney - Date: Tue, 15 Sep 2020 00:22:30 + (UTC) From: John-Mark Gurney To: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-sta...@freebsd.org, svn-src-stable...@freebsd.org Subject: svn commit: r365738 - stable/11/sys/dev/usb/net Author: jmg Date: Tue Sep 15 00:22:30 2020 New Revision: 365738 URL: https://svnweb.freebsd.org/changeset/base/365738 Log: MFC r365623: Don't clear reserved bits per RealTek This is a direct commit as the driver is significantly different. Modified: stable/11/sys/dev/usb/net/if_ure.c Modified: stable/11/sys/dev/usb/net/if_ure.c == --- stable/11/sys/dev/usb/net/if_ure.c Mon Sep 14 23:51:14 2020 (r365737) +++ stable/11/sys/dev/usb/net/if_ure.c Tue Sep 15 00:22:30 2020 (r365738) @@ -710,7 +710,9 @@ ure_init(struct usb_ether *ue) ~URE_RXDY_GATED_EN); /* Set Rx mode. */ - rxmode = URE_RCR_APM; + rxmode = ure_read_4(sc, URE_PLA_RCR, URE_MCU_TYPE_PLA); + rxmode &= ~URE_RCR_ACPT_ALL; + rxmode |= URE_RCR_APM; /* If we want promiscuous mode, set the allframes bit. */ if (ifp->if_flags & IFF_PROMISC) - End forwarded message ----- -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
Rodney W. Grimes wrote this message on Wed, Oct 24, 2018 at 05:19 -0700: > And I have read case law that boiled down to the presents vs absence > of a comma in an agreement that had results far beyond "minor". For those currious about this case: https://www.bostonglobe.com/business/2017/03/16/lack-oxford-comma-costs-maine-company-millions-overtime-dispute/BIxK837fA2C06qavQMDs5J/story.html -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
Warner Losh wrote this message on Thu, Oct 04, 2018 at 09:53 -0600: > On Thu, Oct 4, 2018 at 9:46 AM Cy Schubert > wrote: > > > I'm willing to help out with rl(4) as I have one here. Others, not > > scheduled for removal, that I can help one way or another are are NICs, > > including wireless, currently installed here. > > > > There's an iflib man page that's a decent place to start. The API has > evolved over time, so corrections to the man page would be welcome (and > committed as quickly as the freeze allows). I'm reading through the current > iflib drivers to see which one would be best to recommend. Can you recommend one? It'd be nice to just document which driver you should use as a reference in the iflib man page... I looked briefly at converting awg over to iflib, but the iflib man pages were very sparce in any text to describe what each function needs to do... It says it in very high level, which is useful if you already know what needs to be done.. for example: ifdi_tx_queues_alloc() Mandatory function that is called during iflib_attach to allocate transmit queues. vaddrs and paddrs are arrays of virtual and physical addresses respectively of the hardware transmit queues. ntxqs is the number of queues per qset. ntxqsets is the number of qsets. It says it allocates memory for the queue, but upon allocation where does it put the values? It sounds like vaddrs and paddrs arrays are already allocated and you just use these addresses... But there is no way I can write code from this description... Also, lots of terminology is missing, like what is a qset? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: changes in iostat output in 11.x vs 10.x
Miroslav Lachman wrote this message on Sun, Aug 19, 2018 at 02:29 +0200: > I upgraded one of our servers from 10.4 to 11.2 and scripts using output > of "iostat -x" are not working anymore. > A checked the output of iostat and it is different. Looks like this was changed in r277566[1] by will. I've cc'd him. There is no documentation change associated w/ this change. [1] https://svnweb.freebsd.org/base?view=revision=277566 > # on 10.4 > > # iostat -w 5 -c 2 -x ada0 ada1 > extended device statistics > device r/s w/skr/skw/s qlen svc_t %b > ada0 51.5 28.3 1381.4 539.70 9.7 33 > ada1 51.4 28.2 1381.5 539.70 10.1 34 > extended device statistics > device r/s w/skr/skw/s qlen svc_t %b > ada0 0.2 6.4 2.4 136.50 2.9 2 > ada1 0.0 5.8 0.0 136.50 3.4 2 > > > # on 11.2 > > # iostat -w 5 -c 2 -x ada0 ada1 > extended device statistics > device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b > ada0 6 24 35.9697.9 2 177 30 6 > ada1 6 23 34.9697.9 2 177 30 6 > extended device statistics > device r/s w/s kr/s kw/s ms/r ms/w ms/o ms/t qlen %b > ada0 0 21 0.0776.6 0 096 20 5 > ada1 0 21 0.0776.6 0 0 100 20 5 > > But I cannot find the explanation of new columns. The manpage seems the > same for 10.4 and 11.2 > > The extended iostat device display, with the -x flag specified, > shows the following statistics: > > r/s read operations per second > w/s write operations per second > kr/s kilobytes read per second > kw/s kilobytes write per second > qlen transactions queue length > svc_t average duration of transactions, in milliseconds > %b % of time the device had one or more outstanding transac- > tions > > But there is no svc_t column anymore and there are ms/r ms/w ms/o and > ms/t columns not mentioned in man page. > > Is it a documentation bug? > > Is ms/t the same what was previously known as svc_t? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problem with geli and LSI controller
Marc UBM Bocklet wrote this message on Mon, Jul 20, 2015 at 15:29 +0200: On Mon, 20 Jul 2015 14:56:46 +0200 Marc UBM Bocklet u...@u-boot-man.de wrote: This sounds like the drives were in raid0 mode, and not raw disk mode... You might be able to recover the disk w/ geli resize, assuming only space was added at the end, not at the begining, but I have never personally tried that myself... I'd recommend trying on a copy of the drive so you don't loose data if that is possible.. And one more question, directed at the list: even if geli manages to move the metadata via resize, the gpart metadata is probably still lost? It depends.. did you gpart it first and the geli it? or the other way around? If you gpart'd it first, you should be able to see your partitions, if you can't then getting a replacement controller card makes the most sense, as it's likely that the RAID card meta data is at the begining of the drive... gpart also supports the resize command... Replying to myself again, it appears that the safest way is to get a Rocket Raid controller identical to the one we had, put it in another system, connect the disks, import the old pool and move the data to the new pool on the the LSI controller. Am I overlooking anything? Nope... As someone else said, this is the dangers of RAID cards... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problem with geli and LSI controller
Marc UBM via freebsd-stable wrote this message on Sun, Jul 19, 2015 at 17:34 +0200: a few weeks ago our Highpoint Rocket Raid controller (hptrr) started biting the dust (spurious channel resets). We bought a LSI 9201-16i (mps) to replace it. Connected to the hptrr were 4 external e-sata enclosures, configured in JBOD mode. Together with two disks connected to the onboard SATA controller, this formed a geli encrypted raidz-2 zpool. Just now, I connected the disks to the mps controller. They show up fine in dmesg. The problem is, when trying to attach the disks formerly connected to the hptrr controller, geli is unable to find the metadata on the disks and errors out with: geli: Cannot read metadata from /dev/da4: Invalid argument gpart show says gpart: No such geom: da4 Trying to restore the geli metadata gives: geli: Provider size mismatch: wrong backup file? Is it possible that the hptrr controller handled the disks in some special way and it's only possible to read them there? This sounds like the drives were in raid0 mode, and not raw disk mode... You might be able to recover the disk w/ geli resize, assuming only space was added at the end, not at the begining, but I have never personally tried that myself... I'd recommend trying on a copy of the drive so you don't loose data if that is possible.. You can also try to find the old geli label w/ a command like: dd if=disk bs=1m iseek=location count=5 | strings -n 9 -td And get current disk size using diskinfo... Something like: #diskinfo /dev/ada0 /dev/ada0 512 3000592982016 5860533168 40960 5814021 16 63 #dd if=/dev/ada0 iseek=$((3000592982016/1024/1024-1)) bs=1m 2/dev/null | strings -n 6 -td | grep GEOM:: 1530880 GEOM::ELI 1531392 GEOM::LABEL You might have to go farther back than 1 MB... Good luck... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.X+ securelevel=2 S.M.A.R.T.?
Todor Todorov wrote this message on Fri, Jul 03, 2015 at 08:50 +0300: I know it's not a new topic but still did not find a proper solution. As all know starting from 9.X branch the disk access is changed and using securelevel=2 breaks the smartmontools to get disk health status. Is there a way to keep both security and functionality as in previous releases? Any ideas, articles, guides? Per the securelevel man page: 2 Highly secure mode - same as secure mode, plus disks may not be opened for writing (except by mount(2)) whether mounted or not. smartmontools uses a special passthrough mode of the disk to send custom commands to the disk... If the passthrough mode is allowed in this level, then smartmontools could write to the disk violating the guarantee that disks may not be written to in multiuser mode... This is probably a result of the switch from the old ata framework to now where ata is part of the cam framework... I'd say that the fact smartmontools worked pre 9.x is a bug... You might want to look at the MAC framework[1] where you can have finer grained control of what is allowed and disallowed on your system if you care this much about security... [1] https://www.freebsd.org/doc/handbook/mac.html -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 35-40% performance drop releng9 vs releng10 openvpn
Mike Tancsa wrote this message on Wed, Mar 18, 2015 at 15:49 -0400:
On 3/16/2015 9:20 AM, John-Mark Gurney wrote:
Since you have at test framework ready, you could generate some flame
graphs[1] using dtrace to help see where things might be having an
impact...
These are very easy to generate, and posting them would be useful...
[1] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
Hi,
I went through the steps to generate one. What args should I use for
dtrace to generate the information that is helpful / useful ? For my
setup, I have
server1-apu-server2
server1 has an openvpn tunnel to the apu
I route server2's IP address across the VPN tunnel, so if I ping from
server1 to server2's IP, it goes via the tunnel
on the
dtrace -x ustackframes=100 -n 'profile-99 /execname == openvpn
arg1/ { @[ustack()] = count(); } tick-30s { exit(0); }' -o 10.stacks
which generated
http://tancsa.com/10.svg
So, I would first identify the machine w/ the cpu limited load.. I
assume that is apu... Then I would look at where most of the cpu time
is being spent, be it openvpn itself, or in the kernel... Most likely
it is the kernel, so getting stacks from the kernel would be more useful
than the one you generated... Use the command:
# dtrace -x stackframes=100 -n 'profile-997 /arg0/ { @[stack()] = count(); }
tick-60s { exit(0); }' -o out.kern_stacks
Also, another thing you can do is to compare the two using differential
flame graphs:
http://www.brendangregg.com/blog/2014-11-09/differential-flame-graphs.html
Which will highlight where the performances differ...
As I've never used OpenVPN before and their docs don't go into saying
what it's using.. Is OpenVPN a kernel or userland VPN? Do they use
IPSec in the kernel? or are they just using UDP or TCP for their
connections?
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 35-40% performance drop releng9 vs releng10 openvpn
Mike Tancsa wrote this message on Sun, Mar 15, 2015 at 20:34 -0400: As part of moving from a RELENG8 based image to a RELENG9 or 10, I was doing some simple performance testing and found RELENG_9 to be quite a bit faster when generating traffic through a pcengines APU (dual core, AMD64, 2G of RAM). Both are using generic kernels blasting across an aes-128cbc tunnel, on releng9 I get # dd if=/dev/zero | nc 10.3.24.25 500 326002688 bytes transferred in 37.188139 secs (8766308 bytes/sec) vs # dd if=/dev/zero | nc 10.3.24.25 500 146982400 bytes transferred in 27.750440 secs (5296579 bytes/sec) on releng10. Both have identical pf rules, but disabling pf does not make much of a difference in speed. I havent started checking any of the default tunables. The box will be functioning as a VPN router and I was hoping to get at least 50Mb/s out of it, and I can do that on RELENG9, but not 10. Any ideas what to do with RELENG10 to get comparable performance out of it ? Since you have at test framework ready, you could generate some flame graphs[1] using dtrace to help see where things might be having an impact... These are very easy to generate, and posting them would be useful... [1] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible kqueue related issue on STABLE/RC.
Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +0300: On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: I'd like to understand why you think protecting these functions w/ the _DETACHED check is correct... In kern_event.c, all calls to f_detach are followed by knote_drop which will ensure that the knote is removed and free, so no more f_event calls will be called on that knote.. My current belief is that what happens is a glitch in the kqueue_register(). After a new knote is created and attached, the kq lock is dropped and then f_event() is called. If the vnode is reclaimed or possible freed meantime, f_event() seems to dereference freed memory, since kn_hook points to freed vnode. Well, if that happens, then the vnode isn't properly clearing up the knote before it gets reclaimed... It is the vnode's responsibility to make sure any knotes that are associated w/ it get cleaned up properly.. The issue as I see it is that vnode lifecycle is detached from the knote lifecycle. Might be, only the second patch, which acquires a hold reference on the vnode for each knote, is really needed. But before going into any conclusions, I want to see the testing results. The vnode lifecycle can't/shouldn't be detached from the knote lifecycle since the knote contains a pointer to the vnode... There is the function knlist_clear that can be used to clean up knotes when the object goes away.. I was looking at the code, is there a good reason why you do VI_LOCK/VI_UNLOCK to protect the knote fields instead of getting it in the vfs_knllock/vfs_knlunlock functions? Because kq code will modify the knote fields w/ only running the vfs_knllock/vfs_knlunlock functions, so either the VI_LOCK/VI_UNLOCK are unnecessary, or should be moved to vfs_knllock/vfs_knlunlock... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible kqueue related issue on STABLE/RC.
Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 22:40 +0300:
On Wed, Sep 25, 2013 at 09:19:54AM -0700, John-Mark Gurney wrote:
Konstantin Belousov wrote this message on Wed, Sep 25, 2013 at 00:21 +0300:
On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote:
I'd like to understand why you think protecting these functions w/
the _DETACHED check is correct... In kern_event.c, all calls to
f_detach are followed by knote_drop which will ensure that the knote
is removed and free, so no more f_event calls will be called on that
knote..
My current belief is that what happens is a glitch in the
kqueue_register(). After a new knote is created and attached, the kq
lock is dropped and then f_event() is called. If the vnode is reclaimed
or possible freed meantime, f_event() seems to dereference freed memory,
since kn_hook points to freed vnode.
Well, if that happens, then the vnode isn't properly clearing up the
knote before it gets reclaimed... It is the vnode's responsibility to
make sure any knotes that are associated w/ it get cleaned up properly..
See below.
The issue as I see it is that vnode lifecycle is detached from the knote
lifecycle. Might be, only the second patch, which acquires a hold
reference
on the vnode for each knote, is really needed. But before going into any
conclusions, I want to see the testing results.
The vnode lifecycle can't/shouldn't be detached from the knote lifecycle
since the knote contains a pointer to the vnode... There is the function
knlist_clear that can be used to clean up knotes when the object goes
away..
This is done from the vdropl() (null hold count) - destroy_vpollinfo().
But this is too late, IMO. vdropl() is only executing with the vnode
interlock locked, and knote lock is vnode lock. This way, you might
get far enough into vdropl in other thread, while trying to operate on
a vnode with zero hold count in some kqueue code path.
We do not drain the vnode lock holders when destroying vnode, because
VFS interface require that anybody locking the vnode own a hold reference
on it. My short patch should fix exactly this issue, hopefully we will see.
Which clearly wasn't happening before... With the above, and rereading
your patch, I understand how this patch should fix the issue and bring
the life cycle of the two back into sync...
I was looking at the code, is there a good reason why you do
VI_LOCK/VI_UNLOCK to protect the knote fields instead of getting it in
the vfs_knllock/vfs_knlunlock functions? Because kq code will modify
the knote fields w/ only running the vfs_knllock/vfs_knlunlock functions,
so either the VI_LOCK/VI_UNLOCK are unnecessary, or should be moved to
vfs_knllock/vfs_knlunlock...
vfs_knllock() is fine. The problematic case if the
VOP_{PRE,POST}-VFS_KNOTE-VN_KNOTE-KNOTE calls from the VOPs. If you
look at the vfs_knl_assert_locked(), you would note that the function
only asserts that vnode is locked, not that it is locked exclusively.
This is because some filesystems started require from VFS to do e.g.
VOP_WRITE() with the vnode only shared-locked, and KNOTE() is called
with shared-locked vnode lock.
The vfs_knllock() obtain the exclusive lock on the vnode, so kqueue
callers are fine. Taking vnode interlock inside the filters provides
enough exclusion for the VOP callers.
Ahh, ok, makes sense now.. Clearly I need to learn more about the
VFS/vnope system.. :)
Thanks for the explanations...
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Possible kqueue related issue on STABLE/RC.
) at /usr/src/sys/kern/vfs_vnops.c:1398
1398KASSERT(vp-v_holdcnt != 0,
(kgdb) l
1393
1394VNASSERT((flags LK_TYPE_MASK) != 0, vp,
1395(vn_lock called with no locktype.));
1396do {
1397#ifdef DEBUG_VFS_LOCKS
1398KASSERT(vp-v_holdcnt != 0,
1399(vn_lock %p: zero hold count, vp));
1400#endif
1401error = VOP_LOCK1(vp, flags, file, line);
1402flags = ~LK_INTERLOCK; /* Interlock is always
dropped. */
the vp is =
(kgdb) p *(struct vnode *) 0xfe018afd
$2 = {v_type = VDIR, v_tag = 0x80f56e88 ufs, v_op =
0x8132c800, v_data = 0xfe013a2a7348, v_mount =
0xfe0009c00b70, v_nmntvnodes = {
tqe_next = 0xfe018ace3520, tqe_prev = 0xfe018afd02b8}, v_un =
{vu_mount = 0x0, vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0},
v_hashlist = {
le_next = 0x0, le_prev = 0xff8000e29f00}, v_hash = 236846,
v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last =
0xfe018afd0060},
v_cache_dd = 0x0, v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0,
v_lock = {lock_object = {lo_name = 0x80f56e88 ufs, lo_flags =
91947008, lo_data = 0,
lo_witness = 0xff80006c3400}, lk_lock = 1, lk_exslpfail = 0,
lk_timo = 51, lk_pri = 96, lk_stack = {depth = 12, pcs =
{18446744071571296822,
18446744071573768620, 1844674407157639, 18446744071606114523,
1844674407157639, 18446744071572113991, 18446744071572067715,
18446744071606111219,
18446744071572016126, 18446744071572018094, 18446744071575427509,
18446744071575340439, 0, 0, 0, 0, 0, 0}}}, v_interlock = {lock_object = {
lo_name = 0x80f6f8e3 vnode interlock, lo_flags = 16973824,
lo_data = 0, lo_witness = 0xff80006a9600}, mtx_lock = 4}, v_vnlock =
0xfe018afd0098,
v_holdcnt = 0, v_usecount = 0, v_iflag = 256, v_vflag = 0, v_writecount =
0, v_actfreelist = {tqe_next = 0xfe018ace3cd0, tqe_prev =
0xfe00aefe6e78},
v_bufobj = {bo_mtx = {lock_object = {lo_name = 0x80f7822c bufobj
interlock, lo_flags = 16973824, lo_data = 0, lo_witness =
0xff80006b1680},
mtx_lock = 4}, bo_clean = {bv_hd = {tqh_first = 0x0, tqh_last =
0xfe018afd01d8}, bv_root = 0x0, bv_cnt = 0}, bo_dirty = {bv_hd =
{tqh_first = 0x0,
tqh_last = 0xfe018afd01f8}, bv_root = 0x0, bv_cnt = 0},
bo_numoutput = 0, bo_flag = 0, bo_ops = 0x812f99a0, bo_bsize =
32768,
bo_object = 0xfe01f8a6c570, bo_synclist = {le_next =
0xfe018afd0448, le_prev = 0xfe00096d5ca0}, bo_private =
0xfe018afd,
__bo_vnode = 0xfe018afd}, v_pollinfo = 0xfe0056b05380,
v_label = 0x0, v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0,
tqh_last = 0xfe018afd0278}, rl_currdep = 0x0}}
I'd like to understand why you think protecting these functions w/
the _DETACHED check is correct... In kern_event.c, all calls to
f_detach are followed by knote_drop which will ensure that the knote
is removed and free, so no more f_event calls will be called on that
knote..
Thanks.
@@ -4412,17 +4415,23 @@ filt_vfsdetach(struct knote *kn)
struct vnode *vp = (struct vnode *)kn-kn_hook;
KASSERT(vp-v_pollinfo != NULL, (Missing v_pollinfo));
+ kn-kn_hook = NULL;
knlist_remove(vp-v_pollinfo-vpi_selinfo.si_note, kn, 0);
+ vdrop(vp);
}
/*ARGSUSED*/
static int
filt_vfsread(struct knote *kn, long hint)
{
- struct vnode *vp = (struct vnode *)kn-kn_hook;
+ struct vnode *vp;
struct vattr va;
int res;
+ if ((kn-kn_status KN_DETACHED) != 0)
+ return (0);
+ vp = (struct vnode *)kn-kn_hook;
+
/*
* filesystem is gone, so set the EOF flag and schedule
* the knote for deletion.
@@ -4448,8 +4457,11 @@ filt_vfsread(struct knote *kn, long hint)
static int
filt_vfswrite(struct knote *kn, long hint)
{
- struct vnode *vp = (struct vnode *)kn-kn_hook;
+ struct vnode *vp;
+ if ((kn-kn_status KN_DETACHED) != 0)
+ return (0);
+ vp = (struct vnode *)kn-kn_hook;
VI_LOCK(vp);
/*
@@ -4467,9 +4479,12 @@ filt_vfswrite(struct knote *kn, long hint)
static int
filt_vfsvnode(struct knote *kn, long hint)
{
- struct vnode *vp = (struct vnode *)kn-kn_hook;
+ struct vnode *vp;
int res;
+ if ((kn-kn_status KN_DETACHED) != 0)
+ return (0);
+ vp = (struct vnode *)kn-kn_hook;
VI_LOCK(vp);
if (kn-kn_sfflags hint)
kn-kn_fflags |= hint;
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has
Re: Rescuing a GPT ZFS boot setup
Andy Moran wrote this message on Thu, Sep 19, 2013 at 08:12 -0700: On Sep 19, 2013, at 6:58 AM, Volodymyr Kostyrko c.kw...@gmail.com wrote: 19.09.2013 16:43, Andrew Moran wrote: Alas, that did not work. But it does look to be BIOS related. I think this new system has a UEFI bios. I just read from https://wiki.freebsd.org/UEFI: * Partitions not seen. When using GPT, FreeBSD will create a protective MBR. This MBR has one partition entry covering the whole disk. FreeBSD marks this partition active. This causes at least some UEFI implementations to ignore the GPT. To fix this the partition needs to be marked inactive. * Filesystem not seen. FreeBSD's FAT32 code appears to sometimes create filesystems that the UEFI code can't properly read. If the filesystem is small enough, use FAT16 or FAT12 instead. I think this may be my issue. But 9.1 LiveCD does boot and I can see the data once booted, so there must be a way to fix the boot loader on the drive to work. Good catch. The fix landed in stable not so long ago (http://svnweb.freebsd.org/base?view=revisionrevision=255017) so you wouldn't find it in 9.2 either. Can you try this: gpart unset -a active ada0 It says 'active' is an invalid attribute. This matches what gpart mangpage says under ATTRIBUTES .. it doesn't list 'active' as an attribute for the GPT partition scheme (but it does for other schemes).I did try to unset 'bootme' but that did not help either. Do I need the newer version of gpart to be able to unset or set it? You could try the new 10-ALPHA1 LiveCD to unset it.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Lev Serebryakov wrote this message on Tue, Sep 17, 2013 at 23:08 +0400: Hello, Harald. You wrote 17 2013 ??., 21:43:17: HS Is that worth a try? HS http://www.asix.com.tw/FrootAttach/driver/MCS7840_7820_FreeBSD_driver_v1.1.zip Nope. I've started from this driver, and it even doesn't support BREAK signal (it is was first reason why I start to write new one -- I needed BREAK to enter kernel debugger). You do know of: # Solaris implements a new BREAK which is initiated by a character # sequence CR ~ ^b which is similar to a familiar pattern used on # Sun servers by the Remote Console. There are FreeBSD extensions: # CR ~ ^p requests force panic and CR ~ ^r requests a clean reboot. options ALT_BREAK_TO_DEBUGGER to add to your kernel file right? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: patch to improve AES-NI performance
Outback Dingo wrote this message on Tue, Aug 27, 2013 at 19:01 -0400: On Sun, Aug 25, 2013 at 10:19 AM, Ollivier Robert robe...@keltia.freenix.fr wrote: According to Ollivier Robert: You are right, I wanted to say r226837 which is the code one. FYI I've finally merged r226837,r226839 as r254856 in stable/9 as it is a prerequesite to apply jmg's patch. I've asked re@ whether they would consider this for 9.2. It is very late in the 9.2 release circle but that patch has been in 10 for more than a year now... So this patch can now be applied to STABLE/9 for testing on a local system since these 3 revisions are now in?? I've compile tested the patch, but not run tested it: https://people.freebsd.org/~jmg/aesni.9stable.patch Note that 9stable uses gcc by default and this patch required clang, so make sure you set WITH_CLANG=YES WITH_CLANG_IS_CC=YES, otherwise it won't compile... This patch only required minor changes from my original patch to apply.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Apparent fxp regression in FreeBSD 8.4-RC3
Hiroki Sato wrote this message on Fri, May 24, 2013 at 16:36 +0900: Hiroki Sato h...@freebsd.org wrote in 20130524.162926.395058052118975996@allbsd.org: hr YongHyeon PYUN pyu...@gmail.com wrote hr in 20130524054720.ga1...@michelle.cdnetworks.com: hr hr A workaround is specifying the following line in rc.conf: hr hr ifconfig_fxp0=DHCP media 100baseTX mediaopt full-duplex Hmm, I guess this can happen on other NICs when the link negotiation causes a link-state flap. Is it true? Just as a bit of history of this change (since I think I may have introduced part of this issue in 163061 of if_fxp.c)... fxp used to previously not drop link when you would switch from autoneg to a fixed media... The problem with this was that if you booted it always defaults to autoneg and if your switch was autoneg, then the switch would negotiate 100/full. If you then manually switched fxp to 100/full, things would be fine till either the switch was reset and/or the cable pulled. Then when the switch came back and was not be able to autoneg, it then would make the link 100/half, which of course would cause problems I made this change because it was better to flap the link on media switch, and force and earlier detection that there was this mismatch between the switch, then possibly months or years later... I actually believe all 100Mbps cards should do this on media change in order to prevent the above issue... Unless of course the card can do both autoneg and fixed media at the same time, which is probably the problem with this fxp chip/phy... Hope this helps with some history behind this issue.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Any objections/comments on axing out old ATA stack?
Alexander Motin wrote this message on Thu, Mar 28, 2013 at 09:17 +0200: On 28.03.2013 02:43, Adrian Chadd wrote: My main concern with the new stuff is that it requires CAM and that's reasonably big compared to the standalone ATA code. It'd be nice if we could slim down the CAM stack a bit first; it makes embedding it on the smaller devices really freaking painful. Are there many boards now with ATA, but without USB? But I agree, it should be checked. The net4501 board has ATA but no USB.. Also, depending upon use, you might choose to not include USB, but use ATA, or not use umass, but the rest of USB... Someone on a list was talking about trying to get FreeBSD down on a really small system, 16MB ram... /me thinks of the old wd driver. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: amdtemp does not find my CPU.
Zoran Kolic wrote this message on Fri, Mar 15, 2013 at 17:15 +0100: After I installed 9.1 amd64 on node with amd 8120, I was not able to read temperatures out of the box. I fetched source for head module and compiled. And loaded module. Still nothing. I assume my cpu is a bit different. Have you tried loading the module at boot time w/ loader.conf? I was just looking at one of my machines that should be supported by amdtemp, but hostb had already attached to it: hostb4@pci0:0:24:3: class=0x06 card=0x chip=0x16031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 15h Processor Function 3' class = bridge subclass = HOST-PCI I haven't done this yet, as my other machine that isn't in production isn't supported by amdtemp, but looks like it may suffer the same issue: hostb4@pci0:0:24:3: class=0x06 card=0x chip=0x14031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD]' device = 'Family 15h (Models 10h-1fh) Processor Function 3' class = bridge subclass = HOST-PCI -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS stalls -- and maybe we should be talking about defaults?
Karl Denninger wrote this message on Tue, Mar 05, 2013 at 06:56 -0600: When it happens on my system anything that is CPU-bound continues to execute. I can switch consoles and network I/O also works. If I have an iostat running at the time all I/O counters go to and remain at zero while the stall is occurring, but the process that is producing the iostat continues to run and emit characters whether it is a ssh session or on the physical console. The CPUs are running and processing, but all threads block if they attempt access to the disk I/O subsystem, irrespective of the portion of the disk I/O subsystem they attempt to access (e.g. UFS, swap or ZFS) I therefore cannot start any new process that requires image activation. Since it seems like there is a thread that is spinning... Has anyone thought to modify kgdb to mlockall it's memory and run it against the current system (kgdb /boot/kernel/kernel /dev/mem), and then when the thread goes busy, use kgdb to see what where it's spinning? Just a thought... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
Ben Morrow wrote this message on Mon, Feb 25, 2013 at 00:28 +: 1. Such buffers exist during the entire program's lifetime even if they aren't actively used/needed by the program. With malloc(3) and friends, you're allocating memory dynamically, and you can free(3) when done with it, rather than just having a gigantic portion of memory allocated sitting around potentially doing nothing. If the 'allocated' memory isn't touched, it will never be paged in. Even once it is paged in, if it then goes back to being unused it can be paged out to swap (when necessary) and then stay there. (It would be nice if there were some way to tell the system 'this memory is dead, don't write it out to swap', but I don't think there is.) madvise(2) w/ MADV_FREE, though there was some discussion on -current about what these different flags will/should do not too long ago... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: re(4) problems with GA-H77N-WIFI
Oliver Fromme wrote this message on Mon, Feb 04, 2013 at 19:15 +0100: I'm running a recent stable/9 (about 14 days old). What's the best way to debug this problem? At the moment I'm not even sure if it's the hardware, or if it's FreeBSD's fault (or my fault) ... Have you tried to disable msi and msix? hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 It could be your motherboard doesn't handle MSI and/or MSI-X properly... [...] re0: Using 1 MSI-X message [...] re1: Using 1 MSI-X message -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: re(4) problems with GA-H77N-WIFI
Oliver Fromme wrote this message on Mon, Feb 04, 2013 at 23:04 +0100: John-Mark Gurney wrote: Oliver Fromme wrote this message on Mon, Feb 04, 2013 at 19:15 +0100: I'm running a recent stable/9 (about 14 days old). What's the best way to debug this problem? At the moment I'm not even sure if it's the hardware, or if it's FreeBSD's fault (or my fault) ... Have you tried to disable msi and msix? hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 I tried these entries in /boot/loader.conf, according to the re(4) manual page: hw.re.msi_disable=1 hw.re.msix_disable=1 Unfortunately it didn't make a difference. Did you try in loader.conf: hw.pci.enable_msix=0 hw.pci.enable_msi=0 To disable MSI for the whole system? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: tws bug ? (LSI SAS 9750)
Jim Harris wrote this message on Fri, Oct 26, 2012 at 13:24 -0700:
On Fri, Oct 26, 2012 at 1:18 PM, John-Mark Gurney j...@funkthat.com wrote:
I'm seeing similar stuff on the hpt27xx driver:
(probe18:hpt27xx0:0:18:0): INQUIRY. CDB: 12 0 0 0 24 0
(probe18:hpt27xx0:0:18:0): CAM status: Invalid Target ID
(probe18:hpt27xx0:0:18:0): Error 22, Unretryable error
Should I make a similar change in sys/dev/hpt27xx/osm_bsd.c? Looks like
there are two CAM_TID_INVALID lines, but from reading the comments, only
the second one should change...
Correct? If so, I'll try making the change and make sure everything
works well.
Yes - I agree that a similar change is needed, and only to the second
one in that file.
Ok, I've tested a patch, and so far things look much better... It shuts
up all the bad probe messges...
Though I ran across a bug where the card went out to lunch giving these
messages:
(da2:hpt27xx0:0:2:0): READ(10). CDB: 28 0 a5 4c ae d8 0 0 58 0
(da2:hpt27xx0:0:2:0): CAM status: SCSI Status Error
(da2:hpt27xx0:0:2:0): SCSI status: OK
(da3:hpt27xx0:0:3:0): READ(10). CDB: 28 0 a5 4c b9 f0 0 0 50 0
(da3:hpt27xx0:0:3:0): CAM status: SCSI Status Error
(da3:hpt27xx0:0:3:0): SCSI status: OK
Scott Long suggested the first part of the patch so that an error is
actually generated... Though it would be good for the sense data to
be set, but not sure where to get it...
Index: osm_bsd.c
===
--- osm_bsd.c (revision 241041)
+++ osm_bsd.c (working copy)
@@ -453,7 +453,7 @@
ccb-ccb_h.status = CAM_BUSY;
break;
default:
- ccb-ccb_h.status = CAM_SCSI_STATUS_ERROR;
+ ccb-ccb_h.status = CAM_AUTOSENSE_FAIL;
break;
}
@@ -569,7 +569,7 @@
vd = ldm_find_target(vbus, ccb-ccb_h.target_id);
if (!vd) {
- ccb-ccb_h.status = CAM_TID_INVALID;
+ ccb-ccb_h.status = CAM_SEL_TIMEOUT;
xpt_done(ccb);
return;
}
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: tws bug ? (LSI SAS 9750)
Jim Harris wrote this message on Fri, Sep 21, 2012 at 20:17 -0700: On Fri, Sep 21, 2012 at 5:37 PM, Mike Tancsa m...@sentex.net wrote: On 9/21/2012 8:03 PM, Jim Harris wrote: . then a lot of . (probe65:tws0:0:65:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe65:tws0:0:65:0): CAM status: Invalid Target ID (probe65:tws0:0:65:0): Error 22, Unretryable error (probe1:tws0:0:1:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe1:tws0:0:1:0): CAM status: Invalid Target ID (probe1:tws0:0:1:0): Error 22, Unretryable error (probe2:tws0:0:2:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe2:tws0:0:2:0): CAM status: Invalid Target ID . . . (probe63:tws0:0:63:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe63:tws0:0:63:0): CAM status: Invalid Target ID (probe63:tws0:0:63:0): Error 22, Unretryable error (probe64:tws0:0:64:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe64:tws0:0:64:0): CAM status: Invalid Target ID (probe64:tws0:0:64:0): Error 22, Unretryable error These can be ignored. CAM is just telling you that there are no devices attached at these target IDs. What about a change similar to what Alexander Motin did in http://lists.freebsd.org/pipermail/svn-src-head/2012-June/038196.html Ah, yes. I was thinking you had CAM_DEBUG enabled which is why you were seeing this spew - but that's not the case. This indeed should be fixed and not just ignored. Seeing the attributions on Alexander's commit, you certainly seem to have a monopoly on controllers that exhibit this problem on FreeBSD. :) I believe the CAM_LUN_INVALID here should be fixed as well, similar to the twa commit. If you send me a revised patch I will commit it. I'm seeing similar stuff on the hpt27xx driver: (probe18:hpt27xx0:0:18:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe18:hpt27xx0:0:18:0): CAM status: Invalid Target ID (probe18:hpt27xx0:0:18:0): Error 22, Unretryable error Should I make a similar change in sys/dev/hpt27xx/osm_bsd.c? Looks like there are two CAM_TID_INVALID lines, but from reading the comments, only the second one should change... Correct? If so, I'll try making the change and make sure everything works well. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: time keeps on slipping... slipping...
Alexander Motin wrote this message on Thu, Oct 11, 2012 at 01:43 +0300: On 08.10.2012 07:02, John-Mark Gurney wrote: I recently put together a new machine w/ a SuperMicro H8SCM and an AMD Opteron 4228 HE... I've having an issue where the clock on the machine skips around... The wierd part is that it's very sudden when it happens... ntp sometimes brings it back, but it can't when the clock gets too far ahread (1000 seconds), ntp dies... In order to catch it happening, I ran a sleep 60 loop fetching time from another server that keeps time correctly via: while sleep 60; do echo -n h2:; nc h2 13; date; ntpdate h2.funkthat.com; done here are some snippits: h2:Sun Oct 7 17:12:54 2012^M Sun Oct 7 17:12:54 PDT 2012 7 Oct 17:12:54 ntpdate[31036]: the NTP socket is in use, exiting h2:Sun Oct 7 17:13:48 2012^M Sun Oct 7 17:20:21 PDT 2012 7 Oct 17:20:21 ntpdate[31045]: the NTP socket is in use, exiting but then ntp brings it back in sync: h2:Sun Oct 7 17:28:49 2012^M Sun Oct 7 17:35:21 PDT 2012 7 Oct 17:35:21 ntpdate[31164]: the NTP socket is in use, exiting h2:Sun Oct 7 17:29:49 2012^M Sun Oct 7 17:29:49 PDT 2012 7 Oct 17:29:49 ntpdate[31170]: the NTP socket is in use, exiting It happens pretty often: Oct 7 00:19:13 gold ntpd[3721]: time reset -785.347912 s Oct 7 00:46:37 gold ntpd[3721]: time reset -392.673256 s Oct 7 01:04:24 gold ntpd[3721]: time reset -785.346533 s Oct 7 15:00:59 gold ntpd[3721]: time reset -392.681720 s Oct 7 16:32:11 gold ntpd[3721]: time reset -392.671268 s Oct 7 17:29:29 gold ntpd[3721]: time reset -392.671752 s Oct 7 18:04:37 gold ntpd[3721]: time reset -785.346987 s but as you can see above, the time slip happens abruptly.. looks like a rounding error or something... I'm now reducing the sleep to 5 seconds... but as you can see the sleep ends a few seconds early and local time suddenly jumped forward 6 minutes 33 seconds... $ sysctl kern.timecounter kern.timecounter.fast_gettime: 1 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) ACPI-safe(850) HPET(950) i8254(0) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 11598 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3257069245 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.ACPI-safe.mask: 16777215 kern.timecounter.tc.ACPI-safe.counter: 4219134510 kern.timecounter.tc.ACPI-safe.frequency: 3579545 kern.timecounter.tc.ACPI-safe.quality: 850 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 2854866610 kern.timecounter.tc.TSC-low.frequency: 10937740 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 $ sysctl kern.eventtimer kern.eventtimer.choice: LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 12217 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.periodic: 0 kern.eventtimer.timer: LAPIC kern.eventtimer.activetick: 1 kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 I have switched my timecounter to HPET to see if things are different... Any clues? Mentioned switching to HPET could tell a lot about the problem. Switching event timer also may be interesting. Since I switch to HPET, it hasn't happened at all in the last 3 days.. Should I try switching back to TSC and switching event timer? do you need any other info, or want me to try anything else? Oh, forgot to include the specific processor info in my previous email: CPU: AMD Opteron(tm) Processor 4228 HE (2800.05-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x600f12 Family = 0x15 Model = 0x1 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x1e98220bSSE3,PCLMULQDQ,MON,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX AMD Features=0x2e500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM AMD Features2=0x1c9bfffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,NodeId,Topology,b23,b24 TSC: P-state invariant, performance statistics -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd
time keeps on slipping... slipping...
-LOCKED] usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ugen0.1: ATI at usbus0 uhub0: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: ATI at usbus1 uhub1: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 ugen2.1: ATI at usbus2 uhub2: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus2 ugen3.1: ATI at usbus3 uhub3: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus3 ugen4.1: ATI at usbus4 uhub4: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus4 ugen5.1: ATI at usbus5 uhub5: ATI EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus5 ugen6.1: ATI at usbus6 uhub6: ATI OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus6 uhub6: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered (probe7:hpt27xx0:0:7:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe7:hpt27xx0:0:7:0): CAM status: Invalid Target ID (probe7:hpt27xx0:0:7:0): Error 22, Unretryable error [lots more hpt27xx probe lines through 254 deleted] da0 at hpt27xx0 bus 0 scbus8 target 0 lun 0 da0: HPT DISK 0_0 4.00 Fixed Direct Access SCSI-0 device da0: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da1 at hpt27xx0 bus 0 scbus8 target 1 lun 0 da1: HPT DISK 0_1 4.00 Fixed Direct Access SCSI-0 device da1: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da2 at hpt27xx0 bus 0 scbus8 target 2 lun 0 da2: HPT DISK 0_2 4.00 Fixed Direct Access SCSI-0 device da2: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da3 at hpt27xx0 bus 0 scbus8 target 3 lun 0 da3: HPT DISK 0_3 4.00 Fixed Direct Access SCSI-0 device da3: 2861588MB (5860533168 512 byte sectors: 255H 63S/T 364801C) da4 at hpt27xx0 bus 0 scbus8 target 4 lun 0 da4: HPT DISK 0_4 4.00 Fixed Direct Access SCSI-0 device da4: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) da5 at hpt27xx0 bus 0 scbus8 target 5 lun 0 da5: HPT DISK 0_5 4.00 Fixed Direct Access SCSI-0 device da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da6 at hpt27xx0 bus 0 scbus8 target 6 lun 0 da6: HPT DISK 0_6 4.00 Fixed Direct Access SCSI-0 device da6: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: OCZ-VERTEX4 1.5 ATA-9 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: OCZ-VERTEX4 1.5 ATA-9 SATA 3.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) ada1: Previously was known as ad1 ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: ST31000340AS SD04 ATA-7 SATA 1.x device ada2: 150.000MB/s transfers (SATA 1.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad2 ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 ada3: ST2000DL003-9VT166 CC32 ATA-8 SATA 3.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad3 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #4 Launched! Timecounter TSC-low frequency 10937740 Hz quality 1000 Enter passphrase for ada0p3: uhub5: 6 ports with 6 removable, self powered uhub2: 6 ports with 6 removable, self powered Trying to mount root from zfs:zroot []... I have switched my timecounter to HPET to see if things are different... Any clues? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: (Possible fix for sbp(4)) Re: Comment out sbp driver from GENERIC
Alberto Villa wrote this message on Tue, Oct 18, 2011 at 14:12 +0200: On Tue, Oct 18, 2011 at 1:48 PM, Wojciech A. Koszek wkos...@freebsd.czest.pl wrote: Commenting a driver out is almost always a bad idea and should be done as a last step. Well, few weeks prior to -RELEASE can be considered a last step. :) Considering that no discussion has happened on the -firewire list, nor does there appear to be any active PRs tracking this, I think it's a bad idea to remove the sbp. If someone spends the time to properly file a bug report, then we can tie the reinclusion of sbp to fixing the PR. If we disabled everything that hangs on one or two systems, we wouldn't have many devices in the kernel. The closest bug I could find that relate to this issue is kern/97208. The last activity on this bug was over two years ago, so clearly not many people are reporting the issue to the propler places (-firewire or PR database). -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 2TB+ on ahd broken? (6.2-R)
John-Mark Gurney wrote this message on Fri, Aug 17, 2007 at 15:46 -0700: I was just attempting to add a RAID shelf to a system w/ an Adaptec 29320 card, and when I export a 7TB disk to the card, and kept getting timeout related issues. The dump is very similar to PR 76178 which appears to be reporting the same issue... I have attached a dmesg w/ the failure... I tried various sizes and 100MB, 500MB and 200MB disks work... When I tried the full 7TB or 2.3TB disk, ahd failed w/ the messages at the end of the dmesg. Is anyone even working on this? As 2TB disks are coming soon, I'd imagine that ahd will need to get fixed before long, or are there just not many people use large disks w/ ahd? For the archives: After additional testing.. It appears that there was issues at U320 speeds even w/ the 500MB disk... Slowing down to U160 made the 500MB disk work, but the 2TB disk wouldn't be recognized... I have also tried a different cable, and w/ the different cable, the 2TB disk shows up at U320 speeds, but sees broken behavior, the same as a small disk... The broken behavior at U320 being transfer rates in the 100-200KB/sec as ahd constantly resets... If ahd isn't getting fixed, can someone recommend a low profile PCI-X Ultra320 card? I found a LSI (mpt) based card, and it's working great... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
2TB+ on ahd broken? (6.2-R)
I was just attempting to add a RAID shelf to a system w/ an Adaptec 29320 card, and when I export a 7TB disk to the card, and kept getting timeout related issues. The dump is very similar to PR 76178 which appears to be reporting the same issue... I have attached a dmesg w/ the failure... I tried various sizes and 100MB, 500MB and 200MB disks work... When I tried the full 7TB or 2.3TB disk, ahd failed w/ the messages at the end of the dmesg. Is anyone even working on this? As 2TB disks are coming soon, I'd imagine that ahd will need to get fixed before long, or are there just not many people use large disks w/ ahd? If ahd isn't getting fixed, can someone recommend a low profile PCI-X Ultra320 card? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Thu Jul 26 14:40:30 PDT 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/splicer Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x441dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,b14 Logical CPUs per core: 2 real memory = 1073676288 (1023 MB) avail memory = 1041502208 (993 MB) ACPI APIC Table: A M I OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 3.0 on pci0 pci1: ACPI PCI bus on pcib1 em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xac00-0xac1f mem 0xfc2e-0xfc2f irq 18 at device 1.0 on pci1 em0: Ethernet address: 00:04:23:be:9c:f4 pcib2: ACPI PCI-PCI bridge at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: PCI-PCI bridge at device 3.0 on pci2 pci3: PCI bus on pcib3 arcmsr0: Areca SATA Host Adapter RAID Controller (RAID6 capable) mem 0xfc3ff000-0xfc3f irq 27 at device 14.0 on pci3 ARECA RAID ADAPTER0: Driver Version 1.20.00.13 2006-8-18 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.36 2005-5-18 ahd0: Adaptec 29320ALP Ultra320 SCSI adapter port 0xb800-0xb8ff,0xb400-0xb4ff mem 0xfc5fe000-0xfc5f irq 26 at device 4.0 on pci2 ahd0: [GIANT-LOCKED] aic7901: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 50-66Mhz, 512 SCBs uhci0: UHCI (generic) USB controller port 0xe800-0xe81f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0xec00-0xec1f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci0: base peripheral at device 29.4 (no driver attached) pci0: base peripheral, interrupt controller at device 29.5 (no driver attached) ehci0: Intel 6300ESB USB 2.0 controller mem 0xfe7ffc00-0xfe7f irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: Intel 6300ESB USB 2.0 controller on ehci0 usb2: USB revision 2.0 uhub2: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 4 ports with 4 removable, self powered pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib4 pci4: display, VGA at device 0.0 (no driver attached) fxp0: Intel 82551 Pro/100 Ethernet port 0xcc00-0xcc3f mem 0xfe6fe000-0xfe6fefff,0xfe6a-0xfe6b irq 17 at device 1.0 on pci4 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:04:23:be:9c:f5 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel 6300ESB UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0
Re: default dns config change causing major poolpah
Doug Barton wrote this message on Thu, Aug 02, 2007 at 03:14 -0700: I've never trusted using a hints file... not for at least a decade, I'm not sure how the hints file could fail, it's a pretty simple mechanism. But you're better off using hints (which go years between updates, and you only need one good server to get your cache primed anyway) OR AXFR, which will keep itself up to date automatically. I've had the hints file fail on my server multiple times since I've been running my servers... DNS breaks and I get a constast stream of messages that have no relationship to a failure to contact a root server... The first time it happened it took me close to a day to find out that a simple refresh of my hints file fixed the problem... Now, when I see that message, I now know to update my hints file, but it isn't very good to require manual updating of the hints file every few years to stave off broken dns. So, mark on up to supporting a dns based distribution of the root... (Not necessarily using the existing root servers, but some method that will ensure that dns will not break just because it does.) -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [resolved, naively] Re: geom vs ich through ar device - benchmarks?
Howard Goldstein wrote this message on Wed, Jul 25, 2007 at 17:24 -0400: Scott Long wrote: ICH5 only support SATA-1. Dang. Does anyone yield SATA-II speeds with the a PCI controller? I'm not sure if 25-30MB/s is even possible with regular PCI You probably mean 250-300MB/s which is what SATA-II is able to support, and no, standard 32bit/33Mhz PCI does not support more than 133MB/sec... You are lucky if you get 110MB/sec due to PCI bus overhead... So, SATA-1 can max out a standard PCI bus... Though many on mobo sata controllers aren't necessarily connected to a PCI bus, and so may not be limited... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DDoS in FreeBSD 6.2-STABLE And Problen With The Clock
ExTaZyTi wrote this message on Mon, Jun 11, 2007 at 18:30 +0300: There are some problems, first DDoS (hardware DDoS) in the system. I compile some program and when start it my system blocks and restart (tested and on other system 6.2-stable and again this DDoS). Please email the FreeBSD security team w/ the program as per: http://www.freebsd.org/security/#how [...] Next problem is the clock, have e 4 minuts different from the world time for my country. I try to fix this with a ntpdate otel.net for example .. this again return 4 minutes different. I try and the date command but it's NOT WORK..You can see: This is because the timezone you are using is incorrect. FreeBSD stores the system time in UTC and then converts to the local timezone. If you use the correct timezone (you can set this by running tzsetup) this should not be a problem. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in BSD tar?
Steven Hartland wrote this message on Tue, May 29, 2007 at 11:46 +0100: - Original Message - From: Colin Percival [EMAIL PROTECTED] - Original Message - From: Colin Percival [EMAIL PROTECTED] tar -xvzf test.tar.gz tar: Ignoring unknown extended header keyword `SCHILY.dev' tar: Ignoring unknown extended header keyword `SCHILY.ino' tar: Ignoring unknown extended header keyword `SCHILY.nlink' cantiquedeno\353l1_loop.wav tar: Error exit delayed from previous errors This looks like fairly typical symptoms of gnutar being broken. What makes you think that the archive created by BSD tar was invalid? As a filename should have no bearing on what extended headers are set. Why not? In this case, bsdtar is detecting that the file name contains non-7-bit-ascii characters and is emitting a pax header for that reason; and since it can't suppress the pax header entirely, it goes ahead and emits the not vital but potentially useful headers for the device #, inode #, number of links, and high precision timestamps. I still see no evidence that bsdtar is doing anything wrong. I suppose this then comes down to the fact that gnu tar is the prevalent version out there and as such with BSD creating archives which are incompatible with that leads to problems. From our side we'll have to switch to using gnutar until this issue is resolved as we need to ensure compatibility. Is the file incorrect when extracted? or is this a mater of gtar throwing an error because of the tar format, and an option to bsdtar could be provided to change the output tar format? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug in BSD tar?
Steven Hartland wrote this message on Wed, May 30, 2007 at 02:08 +0100: - Original Message - From: John-Mark Gurney [EMAIL PROTECTED] Is the file incorrect when extracted? or is this a mater of gtar throwing an error because of the tar format, and an option to bsdtar could be provided to change the output tar format? The file is correct when extracted but gtar is, as you say, throwing an error because of the tar format. The exit error is the issue as in a scripted environment, as we have, the error causes the failure of the whole operation. Have you tried the --format argument to bsdtar? Maybe ustar or pax will make gtar happier... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Native SATA vs. PATA-emulation - difference?
Patrick M. Hausen wrote this message on Mon, May 21, 2007 at 15:18 +0200: Hi, all! On Mon, May 21, 2007 at 02:36:48PM +0200, Oliver Fromme wrote: Are the disk sizes exactly the same in both cases? Please provide dmesg output from the 2nd case (native SATA). Good point ;-) But ... P-ATA emulation: atapci0: ServerWorks HT1000 SATA150 controller port 0xc080-0xc087,0xc000-0xc003,0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb80f mem 0xff3fe000-0xff3f irq 11 at device 14.0 on pci1 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 ad4: DMA limited to UDMA33, device found non-ATA66 cable ad4: 157066MB WDC WD1600YS-01SHB1 20.06C06 at ata2-master UDMA33 ad6: DMA limited to UDMA33, device found non-ATA66 cable ad6: 157066MB WDC WD1600YS-01SHB1 20.06C06 at ata3-master UDMA33 Native S-ATA: atapci0: ServerWorks HT1000 SATA150 controller port 0xc080-0xc087,0xc000-0xc003,0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb80f mem 0xff3fe000-0xff3f irq 11 at device 14.0 on pci1 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 ad4: 157066MB WDC WD1600YS-01SHB1 20.06C06 at ata2-master SATA150 ad6: 157066MB WDC WD1600YS-01SHB1 20.06C06 at ata3-master SATA150 I don't see a difference here that could be the root cause of the problem. Besides, I'm using ad4s1 and ad6s1 as the providers for gmirror, so a few sectors plus/minus at the very end of the raw disk should not matter. That doesn't show the exact size... run diskinfo on each of them and that will tell you the reported to geom size.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swap zone exhausted, increase kern.maxswzone
Marc G. Fournier wrote this message on Sat, May 05, 2007 at 13:15 -0300: - --On Saturday, May 05, 2007 12:06:55 -0400 Kris Kennaway [EMAIL PROTECTED] wrote: On Sat, May 05, 2007 at 12:38:39PM -0300, Marc G. Fournier wrote: What exactly does that one mean? I've searched Google, and all I'm finding is a pointer to swap_pager.c, but nothing else ... What does that one mean? What would cause that sort of error? You need to increase the kern.maxswzone tunable to enable more space ^^^ for active swap. Apparently that doesn't exist on 6-STABLE, although its generating the error? # sysctl kern.maxswzone sysctl: unknown oid 'kern.maxswzone' A tunable doesn't need to exist in the sysctl domain... simply add it to /boot/loader.conf as documented in conf/NOTES or defaults/loader.conf... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swap zone exhausted, increase kern.maxswzone
Marc G. Fournier wrote this message on Sat, May 05, 2007 at 13:42 -0300: On 05/05/07, Marc G. Fournier [EMAIL PROTECTED] wrote: # sysctl kern.maxswzone sysctl: unknown oid 'kern.maxswzone' It is a /boot/loader.conf variable, not in sysctl MIB. Hrmmm ... then how do I know what to increase it to, if I don't know what it currently set to? :( I thought all the /boot/loader.conf variables were viewable read only via sysctl ... ? kinda like nmbclusters: # sysctl -a | grep nmbcl kern.ipc.nmbclusters: 25600 I can't set it via sysctl, it has to be in /boot/loader.conf ... but I can at least view its value ... Take a peek at sys/kern/subr_param.c: #ifdef VM_SWZONE_SIZE_MAX maxswzone = VM_SWZONE_SIZE_MAX; #endif TUNABLE_INT_FETCH(kern.maxswzone, maxswzone); and then: crijmgmac,ttyp8,~/FreeBSD/HEAD/src/sys,507$find . -type f | xargs grep VM_SWZONE_SIZE_MAX ./amd64/include/param.h:#ifndef VM_SWZONE_SIZE_MAX ./amd64/include/param.h:#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) ./boot/common/loader.8:.Dv VM_SWZONE_SIZE_MAX . ./conf/options:VM_SWZONE_SIZE_MAX opt_param.h ./i386/include/param.h:#ifndef VM_SWZONE_SIZE_MAX ./i386/include/param.h:#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) ./kern/subr_param.c:#ifdef VM_SWZONE_SIZE_MAX ./kern/subr_param.c:maxswzone = VM_SWZONE_SIZE_MAX; So, it appears that loader(8) isn't correct: swap the system can support. This value is specified in bytes of KVA space and defaults to around 70MBytes. Care It appears that when dillion made the change almost 5 years ago, he didn't update loader(8)... I'll fix that... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swap zone exhausted, increase kern.maxswzone
Marc G. Fournier wrote this message on Sat, May 05, 2007 at 14:30 -0300: But, based on the 'default 70MB == 14G of configured swap' above .. I only have 8G of swap on that machine, which really makes it sound like this is an overflow from the other problem :( If you do have 8gigs of swap, then you do need to increase the parameter.. The default is 7.7gigs of supported swap... (assuming that struct swblock hasn't changed size... The maxswblock only limits it... If swap is more than 8x memory, then changing kern.maxswzone will not fix it and will require a code change... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: swap zone exhausted, increase kern.maxswzone
Matthew Dillon wrote this message on Sat, May 05, 2007 at 10:46 -0700: Basically maxswzone is the amount of KVM the kernel is willing to ^ maximum use to store 'struct swblock' structures. If the 8x memory limit hits first (specificly page_count / 2 * sizeof(struct swblock) is smaller than maxswzone), maxswzone will be ignored... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What triggers No Buffer Space Available?
Marc G. Fournier wrote this message on Wed, May 02, 2007 at 14:34 -0300: Is there any way of determining which apps are holding open which sockets? ie. lsof for open files? netstat -A will list the socket address, fstat will list the fd, and what socket it connected to that fd.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible mtu bug in vlan or bce
Tom Judge wrote this message on Mon, Apr 16, 2007 at 18:21 +0100: I have seen some strange behaviour today with VLAN interfaces on bce interfaces. I am running 6.2 Release on i386. I have a bce interface setup on a gig-e network with an MTU of 8192 i attach a vlan interface to this and chnage the vlan if mtu to 1500 as it has 100Mbit devices on it. This does not seem to affect the MTU of the bce interface, the VLAN mtu is reported as changed by if config but the bce is not reported as changed. However I then start to get error messages saying that the NFS server is not responding as it is sending packets larger than 1500 bytes. If I try to raise the mtu of the vlan interface (to 8192 which is the value that ifconfig reports for bce0) at this stage ifconfig thows an error saying that the value is incorrect. If I then 'raise' (it already appears to be set to 8192 according to ifconfig) the mtu of bce0 to 8192 and then set the vlan interface mtu to 8192 the nfs server starts to work again. Make sure that you change the host route's mtu down to the new MTU... I changed the MTU behavior a while back so that you could have a mixed network and support both large and regular sized MTU's on the same nextwork... # ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 9000 options=18bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,TSO4 inet6 fe80::207:e9ff:fe0d:ad06%em0 prefixlen 64 scopeid 0x2 inet 192.168.0.21 netmask 0xff00 broadcast 192.168.0.255 ether 00:07:e9:0d:ad:06 media: Ethernet autoselect (1000baseTX full-duplex) status: active # netstat -rnWfinet Routing tables Internet: DestinationGatewayFlagsRefs UseMtuNetif Expire default192.168.0.14 UGS 0 8024 1500 em0 [...] 192.168.0.18 00:c0:f0:42:23:87 UHLW12 1500 em0 1193 # route change 192.168.0.18 -mtu 9000 change host 192.168.0.18 # netstat -rnWfinet Routing tables Internet: DestinationGatewayFlagsRefs UseMtuNetif Expire [...] 192.168.0.18 00:c0:f0:42:23:87 UHLW12 9000 em0 1172 # ifconfig em0 mtu 1500 # ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=18bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,TSO4 inet6 fe80::207:e9ff:fe0d:ad06%em0 prefixlen 64 scopeid 0x2 inet 192.168.0.21 netmask 0xff00 broadcast 192.168.0.255 ether 00:07:e9:0d:ad:06 media: Ethernet autoselect (1000baseTX full-duplex) status: active # netstat -rnWfinet Routing tables Internet: DestinationGatewayFlagsRefs UseMtuNetif Expire [..] 192.168.0.18 00:c0:f0:42:23:87 UHLW12 9000 em0 1128 Hmmm... We may want to add code that detects when the host route's MTU is larger than the interface, and prevent that from happening. Though if an mtu daemon ever gets written, then that should take care of it. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dd as an imaging solution.
Sean Bryant wrote this message on Fri, Feb 09, 2007 at 14:07 -0500: John-Mark Gurney wrote: Antony Mawer wrote this message on Tue, Feb 06, 2007 at 17:04 +1100: On 6/02/2007 1:47 PM, Sean Bryant wrote: Dominic Marks wrote: Check out G4U (NetBSD based) The only problem I can see here is that multiple parallel reads will have serious performance impacts, thus greatly increasing the cloning of the disk. The solution with dd, tee and netcat would just daisy chain the copy across the network which would be way faster. Now all you need is G4U to operate in a multicast manner like Symantec Ghost Corporate Edition, and your transfer speed wouldn't reduce with each additional client (eg. 100mbps for 1 client, 50mbps each for 2 clients, 33.3mbps each for 3 clients, ...) Add FEC to the multicast, and you can constantly stream the data, and not have to worry about dropped segments as much... Can you explain this? FEC stands for Forward Error Correction... Check out: http://info.iet.unipi.it/~luigi/fec.html for some work that Luigi has done wrt FEC. I've even embedded his FEC library in the kernel w/o too much difficulty... Wikipedia also has an article on it... So the idea is that you multicast out the data broken up into x packets.. In addition to x packets, you also transmit y parity packets... As long as the end system receives any combination of x and y packets where the total unique packet count is x, you are able to reconstruct the data... You choose y based upon your expected packet drop rate.. This has the advantage that when you are transmitting the data, and a machine fails to receive a packet, you don't have to a) retrainsmit the packet, or b) wait till the same data packet comes along... Because you can replace the missed data packet w/ one of the parity packets to reconstruct the data... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Recommendations for a serial port card you can actually BUY?
Andrew Gordon wrote this message on Fri, Oct 06, 2006 at 14:25 +0100:
Competent USB devices have serial numbers in them, although the current
FreeBSD USB system doesn't provide easy access to the data (the
kernel collects it as part of the device discovery, but AFAIR doesn't do
anything with it). I solved my problems in a different way (below).
I have grown to like how MacOSX uses the serial number for it's tty
devices.. it lets me leave it attached to the device, and know when
I plug it in, I know what tip device to us
So, I decided to add this feature to FreeBSD.. The way the tty handles
serial numbers should change, but this is a first cut... This should
work for tty based USB device assuming that it has a serial number...
-bash-2.05b$ ls /dev/*.F*
/dev/cua.FTC9S0NT /dev/cua.FTC9S0NT.lock /dev/tty.FTC9S0NT.init
/dev/cua.FTC9S0NT.init /dev/tty.FTC9S0NT /dev/tty.FTC9S0NT.lock
-bash-2.05b$ ls /dev/*U0*
/dev/cuaU0 /dev/cuaU0.lock /dev/ttyU0.init
/dev/cuaU0.init /dev/ttyU0 /dev/ttyU0.lock
I have attached the patch...
Comments welcome...
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
//depot/vendor/freebsd/src/sys/dev/usb/ucom.c#46 -
/home/jmg/p4/world/src/sys/dev/usb/ucom.c
--- /tmp/tmp.916.0 Sat Oct 7 03:31:28 2006
+++ /home/jmg/p4/world/src/sys/dev/usb/ucom.c Sat Oct 7 03:18:43 2006
@@ -150,6 +150,7 @@
int
ucom_attach(struct ucom_softc *sc)
{
+ char serial[USB_MAX_STRING_LEN];
struct tty *tp;
int unit;
@@ -167,8 +168,9 @@
tp-t_ioctl = ucomioctl;
DPRINTF((ucom_attach: tty_attach tp = %p\n, tp));
-
- ttycreate(tp, TS_CALLOUT, U%d, unit);
+ usbd_get_string(sc-sc_udev,
+ usbd_get_device_descriptor(sc-sc_udev)-iSerialNumber, serial);
+ ttycreateserial(tp, TS_CALLOUT, serial, U%d, unit);
DPRINTF((ucom_attach: ttycreate: ttyU%d\n, unit));
return (0);
//depot/vendor/freebsd/src/sys/dev/usb/ucomvar.h#8 -
/home/jmg/p4/world/src/sys/dev/usb/ucomvar.h
//depot/vendor/freebsd/src/sys/dev/usb/uftdi.c#24 -
/home/jmg/p4/world/src/sys/dev/usb/uftdi.c
--- /tmp/tmp.916.1 Sat Oct 7 03:31:28 2006
+++ /home/jmg/p4/world/src/sys/dev/usb/uftdi.c Sat Oct 7 03:11:16 2006
@@ -190,13 +190,11 @@
usbd_interface_handle iface;
usb_interface_descriptor_t *id;
usb_endpoint_descriptor_t *ed;
- char *devinfo;
const char *devname;
int i;
usbd_status err;
struct ucom_softc *ucom = sc-sc_ucom;
DPRINTFN(10,(\nuftdi_attach: sc=%p\n, sc));
- devinfo = malloc(1024, M_USBDEV, M_WAITOK);
ucom-sc_dev = self;
ucom-sc_udev = dev;
@@ -222,9 +220,7 @@
iface = uaa-iface;
}
- usbd_devinfo(dev, 0, devinfo);
/* USB_ATTACH_SETUP;*/
- printf(%s: %s\n, devname, devinfo);
id = usbd_get_interface_descriptor(iface);
ucom-sc_iface = iface;
@@ -350,14 +346,12 @@
#endif
DPRINTF((uftdi: in=0x%x out=0x%x\n, ucom-sc_bulkin_no,
ucom-sc_bulkout_no));
ucom_attach(sc-sc_ucom);
- free(devinfo, M_USBDEV);
USB_ATTACH_SUCCESS_RETURN;
bad:
DPRINTF((uftdi_attach: ATTACH ERROR\n));
ucom-sc_dying = 1;
- free(devinfo, M_USBDEV);
USB_ATTACH_ERROR_RETURN;
}
//depot/vendor/freebsd/src/sys/kern/tty.c#106 -
/home/jmg/p4/world/src/sys/kern/tty.c
--- /tmp/tmp.916.2 Sat Oct 7 03:31:28 2006
+++ /home/jmg/p4/world/src/sys/kern/tty.c Sat Oct 7 03:30:05 2006
@@ -2877,15 +2877,45 @@
* XXX: implement the init and lock devices by cloning.
*/
-int
+static int ttycreate_internal(struct tty *tp, int flags, const char *tty,
const char *ser);
+
+int
+ttycreateserial(struct tty *tp, int flags, const char *ser, const char *fmt,
...)
+{
+ char namebuf[SPECNAMELEN - 3]; /* XXX space for tty */
+ va_list ap;
+ int i;
+
+ va_start(ap, fmt);
+ i = vsnrprintf(namebuf, sizeof namebuf, 32, fmt, ap);
+ va_end(ap);
+ KASSERT(i sizeof namebuf, (Too long tty name (%s), namebuf));
+
+ return ttycreate_internal(tp, flags, namebuf, ser);
+}
+
+int
ttycreate(struct tty *tp, int flags, const char *fmt, ...)
{
char namebuf[SPECNAMELEN - 3]; /* XXX space for tty */
+ va_list ap;
+ int i;
+
+ va_start(ap, fmt);
+ i = vsnrprintf(namebuf, sizeof namebuf, 32, fmt, ap);
+ va_end(ap);
+ KASSERT(i sizeof namebuf, (Too long tty name (%s), namebuf));
+
+ return ttycreate_internal(tp, flags, namebuf, NULL);
+}
+
+static int
+ttycreate_internal(struct tty *tp, int flags, const char *tty, const char *ser)
+{
struct cdevsw *csw = NULL;
int unit = 0;
- va_list ap;
struct cdev *cp;
- int i, minor, sminor, sunit;
+ int minor, sminor, sunit
Re: NFS client slow on amd64 6.2-PRERELEASE #2
Jeremy Chadwick wrote this message on Thu, Oct 05, 2006 at 09:08 -0700: The problem in that case turned out to be duplex-related. Both boxes were auto-negotiating with the Cisco switch correctly, and indeed the Cisco labelled them as auto-100/full, but as anyone who is familiar with Ciscos knows, auto-negotiation on Catalysts is far from reliable. Both boxes reported auto-neg and being at 100/full as well. I ended up hard-setting the boxes to use 100/full, and set the switch ports to 100/full, then rebooted both boxes (yes, this is sometimes required, as driver auto-neg code is a bit tweaky); voila, problem fixed. It appears that some ethernet drivers don't reset the phy (bring the link down) when changing media (duplex setting, etc).. This means that if you boot w/ autoselect, and the switch autoselects to 100/full, but then later change it to 100/full (w/ autoselect off) it will work fine.. but then if the cabel is pulled, or the switch resets, it attempts to reautoselect, but falls back to 100/half while you are still running 100/full... As you can imagine, it causes a very hard to track down problem since the time it breaks is not readily apparent... an ifconfig iface down; ifconfig iface up may help resolve this issue if you are not sure... I have just committed a patch to fxp0 to do this... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: large system date skew on RELENG_6 changes causes select() failures
Stanislaw Halik wrote this message on Tue, Sep 05, 2006 at 06:51 +0200: Hello, A while ago, by accident, I've changed the system date back to the '98 using date(1). To my astonishment, screen(1) barfed about EINVAL in select() and died. Programs, including opera (native FreeBSD-6 binary) kept spinning the CPU until I killed them. I have no means for debugging it. Is this somehow expected? If not (i.e. it's a bug), is it known? Probably, they calculated timeout's which magicly became negative, which isn't a valid timeout, and none of the programs are programmed well enough to handle the case and exhibited the behavior that you saw... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld does nothing
Tom Hummel wrote this message on Thu, Aug 17, 2006 at 17:17 +0200: Where did bash come from? It's not part of FreeBSD; I guess you somehow replaced /bin/sh with bash. gosh, no. Bash should be located in /usr/local/bin/ and I invoke it at login for root in chase of an interactive session through ~/.cshrc. I didn't want to change root's login shell into something not part of fbsd-base. If you have bash running out of .cshrc, then that is probably your problem, as csh sources .cshrc each time it runs, so that means any scripts that are csh scripts will not function because bash will start... I added an echo to my .cshrc file: hydrogen,ttype,/home/johng,509$tail -1 .cshrc echo I am csh and I am lame and created this csh script: #!/bin/csh echo foo which results in: hydrogen,ttype,/home/johng,510$/tmp/t.csh I am csh and I am lame foo drop running bash and things will work... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [IMPORTANT] Adaptec no longer supporting iir(4) driver ...
User Freebsd wrote this message on Mon, Jul 31, 2006 at 22:44 -0300: For those that haven't been following the discussion on this, the iir(4) driver in FreeBSD 6.x appears to have a deadlock issue under medium to heavy load, where the 'blocked' state just continues to rise until file accesses just no longer work ... So, if you are running a server that is using the iir(4) device driver and are considering upgrading to FreeBSD 6.x and beyond, or are looking to build a new machine using a device that relies on this driver, do so at your own peril ... Please note that this deadlock issue exists on *both* the ICP Vortex cards, *and* the Intel based RAID controllers ... Have you tried the driver in -current and/or 6.1-R? Specificly v1.14 and v1.13.2.1 of iir.c that limits the simq to 32 commands? We are running w/ this modifications w/o issues on 6.0-R w/ SRCU31A and SRCU42L cards... We have a few GDT cards also that I don't believe we are having any issues with... Infact, scottl tracked down that change after a bit of proding from me on behalf of my employer nCircle... (Though it helped that he was able to reproduce it in his lab.)... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iir(4) driver (Was: Re: Safe card to replace for ICP Vortex GDT851...)
Scott Long wrote this message on Tue, Aug 01, 2006 at 09:35 -0600: FreeBSD. Making big statements in public that they don't, or that it's not up to ones' standards or hopes, isn't terribly useful or productive. I'd hate for FreeBSD to turn into That Other BSD that publically abuses and harasses vendors for percieved sleights. There are much more positive and product ways to fix problems and form good relationships, and those ways are actively being pursued by some people right now. The problem is that these pursuits are not public knowlege, and very often trying to get support through even better than normal channels (i.e. using your system builder's extra clout) doesn't get you this info... The most they tell you is sorry, no support, and we are just being nice to even tell you this since you're running something else... I believe that honest information is better than hopes that turn up fruitless... I've had no end of issues w/ Intel trying to get them to fix various issues w/ their cards (SRCU31A and SRCU42L), and they won't even acknowledge that failing drives due to SELECTION_TIMEOUT, ABORTED COMMAND, OVERLAPPED COMMANDS ATTEMPTED or DISCONNECT_TIMEOUT is a major issue... Due to the fact that SRCU31A is so old, they haven't qualified the newer 2.42 firmware w/ the card... We are going to look at it, since we haven't seen any failed hd's on the 2.42 firmware... And here again is my standard disclaimer: I highly recommend that anyone who takes their data integrity seriously should spend time qualifying any RAID solution that they are interested in before putting it into production. What works for your workload might not work for someone else's workload, and vice-versa. Agreed, luckily we found the hang issue w/ 5.x before we shipped, so we were saved yet another disaster... Patrick M. Hausen wrote: Hello! 'k, just to clarify here ... the new products won't be based on the iir(4) driver then? Yes, they won't. Basically, should the iir(4) driver be considered EOE also? As far as Adaptec and ICP Vortex are concerned, yes. Since the driver is Open Source, there is no enforced EOE, just orphanage, if nobody is willing to work on it. To unsubscribe, send any mail to [EMAIL PROTECTED] -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fsck
gareth wrote this message on Mon, May 15, 2006 at 15:21 +0200: because it changes with every operation and b) should never be checked in that way (that's exactly what fsck means when telling you NO WRITE). ok. but it didn't used to do this, then it started showing up errors on /var, then /var and /tmp. meanwhile the 5 other partitions have never showed up errors. (/tmp /var i spose happen to be small and volatile, but there is another small volatile partition that doesn't show errors. also, the same behaviour shows when i (think) get rid've processes using /tmp) It doesn't matter.. that it used to not do that just means you were lucky, it doesn't mean you were correct.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re driver problem (RTL8169 chipset)
Ganbold wrote this message on Mon, May 08, 2006 at 17:23 +0900: I'm having trouble to make my Netgear Gigabit PCI GA311 network card work in 1000baseTX in FreeBSD-6.1RC. It runs fine on 100baseTX mode with Cat5 cable, however it doesn't with Cat5e/Cat6 cabling in Does it work at 1000baseTX w/ Cat5 cabling? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: re driver problem (RTL8169 chipset)
Ganbold wrote this message on Mon, May 08, 2006 at 17:35 +0900: John-Mark Gurney wrote: Ganbold wrote this message on Mon, May 08, 2006 at 17:23 +0900: I'm having trouble to make my Netgear Gigabit PCI GA311 network card work in 1000baseTX in FreeBSD-6.1RC. It runs fine on 100baseTX mode with Cat5 cable, however it doesn't with Cat5e/Cat6 cabling in Does it work at 1000baseTX w/ Cat5 cabling? I thought Cat5 only supports 100baseTX and I didn't test 1000baseTX w/ Cat5. Nope, 1000Base-T (no X) is speced for Cat5 cabling.. As per the 802.3 spec 40.1: 1000BASE-T signaling requires four pairs of Category 5 balanced cabling, as specified in ISO/IEC 11801:1995 and ANSI/EIA/TIA-568-A (1995) and tested for the additional performance parameters specified in 40.7 using testing procedures defined in proposed ANSI/TIA/EIA TSB95. It is not working at 1000baseTX with Cat5e/Cat6 cabling. It's wierd that it works at 100Base-TX w/ Cat5, but not w/ Cat5e... Is there differences in the cable length or something? Have you tried w/ just normal Cat5? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: link_elf: symbol cam_simq_alloc undefined
Eugene M. Kim wrote this message on Thu, Apr 27, 2006 at 19:55 -0700: I'm trying to upgrade from 5-stable to 6-stable; after rebooting to the new kernel, the amr(4) module (amr.ko) refuses to load with this message: link_elf: symbol cam_simq_alloc undefined However, a quick nm(1) on /boot/kernel/cam.ko does show: ... f0ac T cam_sim_set_path efc4 T cam_simq_alloc efd4 T cam_simq_free ... and cam.ko is already loaded before amr.ko. What am I missing here? *scratches head 'o 'a* amr is missing a: MODULE_DEPEND(amr, cam, 1, 1, 1); which means the module doesn't get cam's symbols... might as well add that line to amr_linux.c next to MODULE_DEPEND already there... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iir + Tyan S2460 + SMP problems
Douglas K. Rand wrote this message on Fri, Apr 21, 2006 at 16:59 -0500: We're having problems with FreeBSD 5.4, 6.0, and 6.1 and an ICP Vortex GDT8546RZ 4 port SATA RAID card in a Tyan S2460 system with dual AMD Athlon MP 1600+ CPUs. We do not have any problems with this configuration under FreeBSD 4.11, and we have the same ICP cards in Tyan based Opterion system (S2882 and S4882) run with out problems under FreeBSD 5.4 and 6.1. We can reproduce the problem on two different S2460 based systems, and have tried 2 seperate ICP GDT8546RZ cards, so we don't believe it is a hardware problem. (Our success with FreeBSD 4.11 also provides some evidence that our hardware is OK.) [...] We've had very similar experiences on 4.7-R. The box would hang on one partition waiting for IO to come back, but direct access to the disk, or accessing other partitions would pass IO fine. This is with Intel SRCU31A and SRCU42L cards. With older GDT cards, it would hang the entire system, since older firmware would completely stop processing commands... Any advice is welcome. Well, except for dump the Tyan S2460 motherboards maybe. How about drop iir? We had serious issues w/ iir on 4.7-R where the system would just hang, and Intel/Adaptect/ICP-Vortex has done zero to help us. Scott Long has done more on his own to help us than the company that produces the card... Make sure that you are running rev 1.13.2.1 of src/sys/dev/iir/iir.c which includes some of scottl's changes to restrict the card to hopefully not hang... btw, Adaptect/ICP-Vortex the latest version of FreeBSD that they support their cards on is 5.2... Any releases beyond that are unsupported, so good luck trying to get them to help you. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: iir + Tyan S2460 + SMP problems
Douglas K. Rand wrote this message on Fri, Apr 21, 2006 at 17:31 -0500: Doug We're having problems with FreeBSD 5.4, 6.0, and 6.1 and an ICP Doug Vortex GDT8546RZ 4 port SATA RAID John-Mark We've had very similar experiences on 4.7-R. The box would John-Mark hang on one partition waiting for IO to come back, but John-Mark direct access to the disk, or accessing other partitions John-Mark would pass IO fine. Interesting, the opposite of our problems. It works perfectly for us on 4.x systems, but not in 5.4 and 6.x. So far we haven't hand any issues w/ 6.0 w/ the iir drivers from 6.1 yet.. but we also haven't deployed our product into production... On 5.4-R we got a few months in before we had the hangs and had to ditch 5.4-R... Doug Any advice is welcome. Well, except for dump the Tyan S2460 Doug motherboards maybe. John-Mark How about drop iir? While not as expensive as switching motherboards, still a pain. We've been very happy with our ICP cards. But your suggestion does have merit, especially as recent PCI-X and PCI-E ICP cards have no FreeBSD driver in sight. I wouldn't be surprised if the other motherboard could exhibit the hang too.. since I believe it's a firmware race condition, and the other motherboard may have different timing characteristics that makes the hang less likely... /me has zero trust in iir cards until Adaptec/ICP-Vortex admits there is a problem and fixes it. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Maximum Swapsize
Michael Schuh wrote this message on Tue, Apr 11, 2006 at 12:56 +0200: My Problem was that i can't show my configured swapsize right... Partitionsize for swap was 4GB Showing Value was 2GB, could you post swapinfo -k and disklabel of the appropriate disks? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usb support kernel changes
Mike Jakubik wrote this message on Sat, Apr 08, 2006 at 02:02 -0400: I have disabled all usb support in my kernel on todays cvs of -stable, and to my surprise i saw it load automatically as a kernel module; # kldstat Id Refs AddressSize Name 14 0xc040 2cac68 kernel 21 0xc06cb000 628f4acpi.ko 31 0xc318b000 1c000usb.ko This is new behavior indeed, how can i disable usb support as before? remove the: usbd_enabled=YES line from your /etc/rc.conf file... and/or remove the various usb lines from your /boot/loader.conf file... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Issues with nullconsole in FreeBSD 6.0-p6
Jonas Blow wrote this message on Tue, Apr 04, 2006 at 00:24 +0200: I've tried to debug the problem. I've not figured out how to remotely debug a kernel when using nullconsole. The escape to debugger hot keys (Ctrl+Alt+Esc or Ctrl+SysReq) does not work when using nullconsole. Therefor it is not possible to switch to remote mode. Can DDB be force to go directly into remote mode? well, one way would be to setup dcons over firewire, and then not use dcons, but use the gdb port to be able to access and manipulate the machine.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Reading via mmap stinks (Re: weird bugs with mmap-ing via NFS)
Mikhail Teterin wrote this message on Sat, Mar 25, 2006 at 09:20 -0500: = The downside is that touching an uncached page triggers a trap which may = not be as efficient as reading a block of data through the filesystem = interface, and I/O errors are delivered via signals (which may not be as = easy to handle). My point exactly. It does seem to be less efficient *at the moment* and I am trying to have the kernel support for this cleaner method of reading *improved*. By convincing someone with a clue to do it, that is... :-) I think the thing is that there isn't an easy way to speed up the faulting of the page, and that is why you are getting such trouble making people believe that there is a problem... To convince people that there is a problem, you need to run benchmarks, and make code modifications to show that yes, something can be done to improve the performance... The other useful/interesting number would be to compare system time between the mmap case and the read case to see how much work the kernel is doing in each case... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: rename
Marcus Alves Grando wrote this message on Sat, Feb 25, 2006 at 13:28 -0300: Xin LI wrote: Hi, Marcus, On 2/25/06, Marcus Alves Grando [EMAIL PROTECTED] wrote: 5.5-PRERELEASE db trace Tracing pid 1114 tid 100303 td 0xc2d07480 kdb_enter(c07025c3) at kdb_enter+0x2b panic(c07102d0,c0744b38,c60eea80,c4ee81c0,c3203420) at panic+0x127 newdirrem(d641d9f8,c32049d8,c57f93d4,0,e768b998) at newdirrem+0x163 What was the panic message? newdirrem: not ATTACHED? newdirrem: inum XXX should be yyy? or newdirrem: whiteout (I guess not, which is only revalent to unionfs)? I access this machine via com1, and i don't know how to see old messages. I can't call doadump because dumpdev=AUTO does not work. You can do: db set $lines = 1 db show msgbuf you can omit the set $lines if you don't mind using the pager... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient in 6.0
David W. Hankins wrote this message on Fri, Feb 03, 2006 at 16:55 -0800: There's no one I think I'm supposed to be talking to about architectural plans like these at FreeBSD. So all these plans Well, you could always check the FreeBSD cvs repository to see who imported dhclient (a hint, it's brooks), and drop him an email... And as the last status report says: OpenBSD dhclient Contact: Brooks Davis [EMAIL PROTECTED] Contact: Sam Leffler [EMAIL PROTECTED] The OpenBSD rewrite of dhclient has been imported, replacing the ISC dhclient. The OpenBSD client provides better support for roaming on wireless networks and a simpler model of operation. Instead of a single dhclient process per system, there is one per network interface. This instance automatically goes away in the even of link loss and is restarted via devd when link is reacquired. To support this change, many aspects of the network interface configuration process were overhauled. Support for adding aliases to DHCP configured interfaces has been committed to CURRENT and will be merged before 6.1-RELEASE. Soon work will begin to merge changes from OpenBSD that have taken place since the initial import. Work on further interface configuration enhancements is underway for FreeBSD 7.0. and both -arch and -current are good places to raise the topic... Good luck in bring things back together... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Jo Rhett wrote this message on Fri, Jan 06, 2006 at 03:03 -0800: On Thu, Jan 05, 2006 at 10:41:47AM -0800, John-Mark Gurney wrote: I believe core has a policy of never supporting vaporware... There is always the chicken and egg problem with arguments like this... I'll code this if you agree to support it and maintain it/I will agree to support it once you code it... In FreeBSD, and many open source projects, no code, no support, how can you support or even agree to support something that doesn't exist? And then as soon as FreeBSD agrees to support something that doesn't exist, either a) other people who were interested in the project stop, even if you end up never producing a bit of code, or b) someone else produces better code, drops the support for the original, but then the author complains about being told they'd support his code, and going with another code base... Bottom line: Once code exists, then support can be talked about.. This is the chicken and egg problem that will kill FreeBSD. I don't And many other open source software projects... FreeBSD isn't unique in this.. I've submitted patches to many other projects just to have them ignored for years too... It's a problem of voluteer orginizations.. bother writing up patches for FreeBSD because every time I do they sit in a PR and get ignored for several years. Then someone that does have commit rights makes their own patch (which often is less useful) but they own it and the best I've ever succeeded at was convincing them to put some of the ideas from my patch into their code. Note that none of these patches were ever rejected for any technical or political or any other reason. They just don't get paid attention to. Thus, I try to get consensus that the idea has merit. IF freebsd committers can be bothered to pay attention to the idea, I'll write code for it. But I'm too old and tired to spend another week writing up something that will get ignored for X years and then dropped for obsoletion again. You're trying to target to large of an audience... You need to get _A_ committer interested in your work, and get HIM to guide you and commit your work... AND there are a lot of opinions and politics around how to version the core that have nothing to do with code. There's no value in writing code that will be ignored because it doesn't agree with -core's view of should be. I'm a coder, not a politician. If we can get consensus on what type of implementation would be acceptable to core, then I and many others would be happy to write code to implement this idea. But this is a considerable amount of work that will be closely tied to the operation system installation. It's not something that you can churn out 7 different implementations of just to see which one fits the current polical environment. stop talking about core... -core makes absolutely no technical decisions about how FreeBSD is.. it is the developers, and previously there was a technical review board for settling differences between developers that were pure technical in nature... And if you claim you didn't know this, then you better read the email you respond to more closely, since this has been pointed out to you numerous times.. and you said in another email: First, this is obvious and true for all open source projects. But no, FreeBSD _never_ advances because someone writes code that does something well. FreeBSD _only_ advances when the core developers agree that this thing is worthy of their interest. hmmm... you really are choosing to completely ignore what people have said about core, that at least you did add developers after core, which makes it appear less likely that you're talking about -core.. but lots of stuff gets done w/o core developers... I did lots of work on -sparc64, and I'm pretty sure you wouldn't call me a core developer.. and I also got TS-7200 arm support (though it hasn't been committed to cvs due to issues that I haven't resolved with device configuration)... As for the whole installation thing, you need to talk with re (release engineering) as they are the ones to really have final say in what installation and releases look like... Back to your finale: Bottom line: Once code exists, then support can be talked about.. This is bullhockey and you know it. Once the project is done, we'll authorize a budget for it? Once the season is over we'll know who should FreeBSD isn't commercial, so you can't talk about budgets... And most orgs want some sort of prototypes and feasibility study done before they'll commit any budget to it... be on the starting team? Yeah, hindsight is sweet. But this isn't a simple change. It will require very close integration with the installation and kernel modules at least (and probably more). So having some sort of consensus that (a) the project has interest and (b) what flavors would be acceptable to the existing groups
Re: Fast releases demand binary updates.. (Was: Release schedule for 2006)
Jo Rhett wrote this message on Thu, Jan 05, 2006 at 01:24 -0800: You are putting words in the mouth of core@ - Sorry. As said before, the topic is always struck down and nobody from core has ever stood up to say we'll support this. I don't know whose on core this week, nor will I at any given time. I just know that core has either struck it down or been Silent. I believe core has a policy of never supporting vaporware... There is always the chicken and egg problem with arguments like this... I'll code this if you agree to support it and maintain it/I will agree to support it once you code it... In FreeBSD, and many open source projects, no code, no support, how can you support or even agree to support something that doesn't exist? And then as soon as FreeBSD agrees to support something that doesn't exist, either a) other people who were interested in the project stop, even if you end up never producing a bit of code, or b) someone else produces better code, drops the support for the original, but then the author complains about being told they'd support his code, and going with another code base... Bottom line: Once code exists, then support can be talked about.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: Please clean out your */etc/rc.d directories
Doug Barton wrote this message on Thu, Dec 22, 2005 at 01:50 -0800: I should have said this in my last heads up message, sorry for forgetting about this important detail. The new code tries to run any script in a local_startup directory (by default /usr/local/etc/rc.d and /usr/X11R6/etc/rc.d) that has the execute bit set. So, if there is a script in one of those directories that you don't want run at all, the safest thing to do is to create a directory within rc.d, and move the script there. Parsing of these scripts is not a recursive operation. The second safest thing to do is to remove the execute bit from those scripts. Does this mean that we will remove the .sh extension on port rc.d startup scripts? Because a) it's been only running .sh scripts for quite a while, and b) it's really nice and easy to disable scripts by moving them to .old or another extension.. Also, how will this effect cups which installs a .sample file? and any other port that does this? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 as storage server with raid5?
Stijn Hoop wrote this message on Fri, Dec 09, 2005 at 10:30 +0100: Besides, I've seen a few hardware RAID controllers having issues themselves (and they weren't the cheapest ones available either). Yep, and because of failure to get proper vender support, software raid is looking more attractive to the company I work at... Delaying upgrades of the OS due to hardware raid issues, and then finding out that the ICP aka Adaptec no longer supports iir beyond 5.2-R (no 5.4-R or any 6.x and beyond) makes it harder for us to justify spending money on hardware raid. (who knows that the next brand of hardware raid isn't going to have the another issue, and decide to not provide support)... At least they finally released a new patch against 5.4-R, but we can barely get them to support us on 4.7-R (which has the same driver as 4.11-R), let alone when we had issues on 5.4-R... So, even though software raid may not be as reliable among other things, at least you have the source and can fix it, and don't have to wait many months just to wait longer for the vendor to fix the issue... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 cron is running on GMT
Brett Glass wrote this message on Sat, Nov 26, 2005 at 22:27 -0700: At 09:14 PM 11/26/2005, Peter Jeremy wrote: On Sat, 2005-Nov-26 15:07:26 -0700, Brett Glass wrote: By the way, the date command does report the correct time. It's cron that seems to be getting the time wrong. You haven't accidently created a line that looks like 'TZ=' in the crontab have you? Nope. Is this affecting all users or just one? All. I am wondering if I shouldn't just redo everything in the system that has to do with time zones and time keeping (deleting files and re-creating them if need be), reboot, and see what happens. I've never seen a good explanation of all of the sysctl variables, environment variables, files, etc. that control it, especially since (as I understand it) the responsibility has been shifted from the kernel to libraries. Is there a summary out there? /etc/localtime contains the timezone that is the default when TZ isn't set... if /etc/wall_cmos_clock exists then the RTC of the machine matches that of /etc/localtime, if it doesn't exist, the RTC is in GMT... adjkerntz(8) contains pointers to these files... as far as I know there are no sysctl's that deal with timezone... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How is the SRCU42X under 6.x ... ?
The Hermit Hacker wrote this message on Fri, Nov 25, 2005 at 19:34 -0400: Found that its supported by the amr vs iir driver ... anyone using/used this with bad experiences? Well, definately look for something that isn't iir based... ICP aka Adaptec does not support iir beyond 5.2-R, so if you run into issues (like we have with GDT and SRCU based cards hanging), hope that you can reproduce on 4.x, else they really won't listen to you.. Though they did finally send us a patch against 5.4-R.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Swapfile problem in 6?
Kris Kennaway wrote this message on Tue, Nov 15, 2005 at 22:35 -0500: What is this serial BREAK? How do I send a serial BREAK at the serial console? Is this some magic key combination? I'm probably saying something about my age by doing this :-} A BREAK (in serial communications) is an absence of start or stop bits for more than a character's worth of bits, is handled as a framing error, and is distinct from any character. If your serial program has trouble sending a break, you can use the ALT_BREAK_TO_DEBUGGER config option which instead listens for a sequence of ascii input: #define KEY_CR 13 /* CR '\r' */ #define KEY_TILDE 126 /* ~ */ #define KEY_CRTLB 2 /* ^B */ ALT_BREAK_TO_DEBUGGER has an advantage over break is that some terminal servers and computers when you turn them off (or power is disconnected) will send a BREAK down the line, which can cause your machine to stop when you didn't want to.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel build fails at 6.0-release!
Giorgos Kapetanakis wrote this message on Fri, Nov 11, 2005 at 23:41 +0200: I just can't build my kernel. I tried several changes at the config file, but I always get the same message. #device ether # Ethernet support (commented out this at v.1.0!!) You need this device!! You can't compile the ethernet drivers w/o this... - linking kernel.debug if.o(.text+0x35a0): In function `if_setlladdr': /usr/src/sys/net/if.c:2152: undefined reference to `arp_ifinit' *** Error code 1 Stop in /usr/obj/usr/src/sys/DEEPBLACK. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --- Can anyone help? Just use the GENERIC kernel next time... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ahd0: Invalid Sequencer interrupt occurred.
Ade Lovett wrote this message on Fri, Nov 11, 2005 at 22:57 -0800: On Nov 11, 2005, at 12:51 , Amit Rao wrote: 0) Upgrade to Seagate 10K.7 drive firmware level 0008. That seems to help. One ahd sequencer error message still appears at boot, but after that it seems to work (with your fingers crossed). Of course, you then spend far too much time ensuring that any replacement drives are flashed appropriately (which, afaict, *requires* Windows to do), and also running the gauntlet of further problems down the road when you throw the drives into a new machine with a subtly different HBA bios. obviously you haven't done any research or even talked with Seagate about this issue... Seagate has a Linux version of their Seagate Enterprise Utility that allows you to flash their drives... /me having had issues with the drives and successfully flashed drives w/o using Windows. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.0 on VMWare 5.0: `calcru: negative runtime of -12728437 usec for pid 28 (irq17: lnc0)'
Lev Serebryakov wrote this message on Wed, Nov 09, 2005 at 10:53 +0300: Hello freebsd-stable, FreeBSD 6.0 on VMWare 5.0 prints such messages every 3-4 minute. Also, messages like calcru: runtime went backwards from 40644816 to 40005944 usec for pid 3 (g_up) is shown routinely. timecounter is ACPI-safe, kernel is GENERIC one. 5.4-STABLE on some virtual machine runs without such messages. And, hey, numbers are TOO big to be true, aren't they? A coworker saw this recently (on 4.x iirc)... and a quick fix was: sysctl kern.timecounter.hardware=i8259 Though I don't know if there is a better fix for it though... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What should be in GENERIC? (was Re: Facilitating binary kernel upgrades)
Miguel wrote this message on Tue, Nov 08, 2005 at 14:09 -0600: John-Mark Gurney wrote: GENERIC is already so large, that if you want/need a smaller kernel, you're going to rebuild anyways, Since I care about that extra 2megs, I recompiled my own kernel, And the real problem of a big kernel is I dont understand exactly why do you have to recompile, unless a new future is needed, like SMP, isnt it?, what harm is doing those extra megs? May be you could clarify on this (for the newbies... :-) ), i always add things to generic instead of cut them down, especially that im not an expert on every future commented there, and i am scared to break working things, openbsd recomends dont recompile, shoul we? In the general case, no, you do not need to recompile.. Those extra megs aren't doing any harm... (besides taking up memory).. I recompile because I'm both familar with the kernel (if I break anything, I can clean it up) , and the extra size of the kernel means that I loose that much memory to running programs... As I said, now days it's not nearly the same, but when I started using FreeBSD, I had 4megs of memory, so saving 300kb was a HUGE deal... In other cases, we use FreeBSD at work on a device w/o swap, and we are constrained by memory, so saving a few megs gives us a bit extra room... Hmmm... maybe we should ship the SMP kernel along with the GENERIC kernel? That'd probably save a bit on new users, though now that we are shipping debug kernels, that'd bloat / by another 20+megs.. :( -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What should be in GENERIC? (was Re: Facilitating binary kernel upgrades)
Colin Percival wrote this message on Tue, Nov 08, 2005 at 08:22 -0800: In deciding what options should go into the GENERIC kernel, I think the question we should be asking is not how many people use this?, but instead would adding this option inconvenience more people than it would help?. GENERIC is already so large, that if you want/need a smaller kernel, you're going to rebuild anyways, so the only people it truely inconviences are the people who just want their system to work w/o extra work... From 5.4-R: -r-xr-xr-x 1 root wheel 5896397 May 8 2005 /boot/kernel.GENERIC/kernel* -r-xr-xr-x 1 root wheel 3508960 Sep 4 15:29 /boot/kernel/kernel* Since I care about that extra 2megs, I recompiled my own kernel, but most systems these days a couple megs isn't that big of a deal, and if you're trying to fit it on a small system, you'll care, and you'll need to recompile anyways... If it doesn't conflict, add it. :) -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: audio (acdt01) dump broken? (BETA4 (5))
Emanuel Strobl wrote this message on Mon, Sep 19, 2005 at 01:44 +0200: tonight I wanted to consolidate (for an upcoming trekstor i.beat organix) my oggs and therefore eval the difference between reencoded [EMAIL PROTECTED][EMAIL PROTECTED] and the original reread wavs(tracks)-[EMAIL PROTECTED] Unfortunately I couldn't grab my CDs anymore. I can remember I had used 'dd if=/dev/acd0txx of=/tmp/track.xx bs=2352' but this doesn't work anymore. I can't replay the bits and with oggenc I get: ERROR: Input file track15.wav is not a supported format [...] What am I missing? That the raw audio data on a cd is raw, and not a wav file... WAV files have a bit of information that contains what the sampling rate is, the channels and the bits per sample: hydrogen,ttyp4,/home/johng,504$file /tmp/quarter.wav /tmp/quarter.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 8 bit, mono 22254 Hz so, if you want, you can use sox to convert the raw audio data into wav: sox -t cdr rawcddata.cdr somefile.wav -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ENOMEM in swap_pager
Kris Kennaway wrote this message on Wed, Sep 14, 2005 at 15:25 -0400: On Wed, Sep 14, 2005 at 09:20:48PM +0200, Ivan Voras wrote: On a P3 server with 1GB of memory, every now and then (about twice a month) I get a log full of errors like this: swap_pager: I/O error - pageout failed; blkno 167,size 4096, error 12 ^^ swap_pager: I/O error - pageout failed; blkno 182,size 4096, error 12 swap_pager: I/O error - pageout failed; blkno 199,size 8192, error 12 swap_pager: I/O error - pageout failed; blkno 12456,size 20480, error 12 swap_pager: I/O error - pageout failed; blkno 222,size 8192, error 12 The server runs fine otherwise, and it doesn't seem to affect applications in any way I'm able to detect. It's running latest 5.4-RELEASE, swap is on a SCSI disk, single processor. IIRC GEOM should handle ENOMEMs by retrying the IO, but I'm asking just in case - are these errors something I should worry about? I/O errors suggest your disk is failing. Unless for some reason his disk is running out of memory: grep 12 /usr/include/errno.h #define ENOMEM 12 /* Cannot allocate memory */ -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB camera
[EMAIL PROTECTED] wrote this message on Thu, Aug 25, 2005 at 09:17 +0100: [EMAIL PROTECTED] wrote: I think there would be a lot of support for this to happen, but it seems to be lacking in leadership and direction at the moment. FreeBSD is not a top-down organization, it is bottom-up. In terms of getting new functionality in, it is not concepts such as leadership and direction that are important, it is volunteers and time and determination. Translation: this won't happen until and unless one or more volunteers step up and put their time into it. Okay I'll rephrase. Somebody did step up, a Video4BSD spec was partially written and is probably still on the web somewhere. There a plenty of people interested in working on this (its probably quite a fun project), but nobody wants to step on anyone else's toes afaict. Yep, I'm still interested, the only problem is lack of time, and also the difficulty/time taken to write a spec and start banging out code... I started writting it, but it's time consuming handling all the constants, etc. necessary for such a large variety of options... If people don't mind a base implementation in python, then I might get back to it... (and let someone else write the C parts of it)... A recommendation to people who are looking at doing a video api, make sure you read through some video docs and think you understand how it works... The Zoran 36067 MJPEG datasheet is what started me on it... they let you hang multiple encoders and decoders on a single video bus... of course you can have only one chip driving a bus at a time, but there are various features like PIP where one chip will not drive the video bus for part of the frame while another chip drives the bus durning this time, and support things like mirroring the data on the bus to both the MJPEG engine, the s-video encoder chip, and the overlay engine for display to the video frame buffer (I don't remeber if the Zoran MJPEG chip supports both MJPEG and video overlay at the same time)... The V4L api lacks these features, though, none of these features are needed for the basic web cam... Another thing that drove me to the design of VideoBSD was the desire to put the least amount of code in the kernel... This would make it easier to plug-in userland usb webcam implementations (like the opti userland usb webcam image capture program that just needs ugen), and not a set of special ioctls for a program to interface with it... Hopefully this will inspire some people... and if someone can get me the specs to the ATI HDTV Wonder card, I'd definately look at reviving the project (I already have the card, just need the specs..) -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network Over Backplane PCI Bus
Jason C. Wells wrote this message on Thu, Aug 25, 2005 at 16:43 -0700: Is there a way to run TCP/IP with the PCI bus as a network interface? You'd have to write your own driver to do it... I am installing FreeBSD on CompactPCI processor boards. It would be really slick if I could network the boards via the PCI backplane. Isn't there usually a single board acting as master, and all the other boards are children of it? There has to be some sort of arbitrator... You could possibly have a master/slave relationship, where the slaves all present a pci device interface with memory buffer to stick received packets, and then the master provides a way to program the slaves where to stick packets in it's memory buffer for transmitted packets.. I've never worked with CompactPCI, so take the above with a grain of salt.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OS suddenly VERY busy
Mikhail T. wrote this message on Wed, Jul 20, 2005 at 00:19 -0400: After a couple of huge tarball extracts (`make extract' in jdk14 and jdk15) I noticed, things are a little slower. During the extracts, the mouse was moving with visible jerks. Indeed, the system seems VERY busy: 11 usersLoad 1.18 1.52 1.40 Jul 20 00:14 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 1060360 105932 1341624 145252 151016 count All 1750432 115908 8911872 174532 pages zfod Interrupts Proc:r p d s wCsw Trp Sys Int Sof Fltcow1277 total 4 1146 1819 345 443k 1640 672 266572 wire 4 irq1: atkb well, I'd say 443k syscalls/time interval isn't doing nothing... [...] The machine is idle and is not doing anything in user-space according to both top and vmstat's pigs display. the problem is that your machine is so fast that all of the processes that are running are exiting before they can be observed by pigs or top (or even accumulate enough cpu time to be worth showing)... Yet it is noticably slower. Trying to compile something pushes the load above 2. What is it doing? This is a single-CPU Opteron running: FreeBSD 5.4-STABLE #0: Fri Jun 10 09:11:30 EDT 2005 amd64 The box has 2Gb of RAM, but NO SWAP. run ps lax a few times, and notice which process is fork bombing your box by seeing which process has the most changing children... (i.e. the ppid, 3rd column, of the process that isn't in the next run)... sort -n +1 -2 + diff will help find which ones... ps lax | sort -n +1 -2 tmpa; sleep 2; ps lax | sort -n +1 -2 tmpb; diff tmpa tmpb look at the ppid (3rd column) of any new or missing processes, and you probably have your culprit... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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
Matthias Buelow wrote this message on Fri, Jul 15, 2005 at 22:11 +0200: for write barriers in the block drivers had been implemented, we phk removed support for write barriers because no one was making use of them... FreeBSD had them, and when there is *CODE* that makes use of them, they'll be added back... As the saying goes: Shut up and code!!! -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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
Matthias Buelow wrote this message on Thu, Jul 14, 2005 at 21:52 +0200: The problem is that disks lie about whether they have actually written data. If the power goes off before the data is in cache, it's lost. No, the problem is that FreeBSD doesn't implement request barriers and that softupdates is flawed by design and seemingly could not make use of them, even if they were available (because, as I understand it, it relies on a total ordering of all writes, unlike the partial ordering necessary for a journalled fs). 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... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is considered the best supported RAID controller for 5.x?
Douglas K. Rand wrote this message on Thu, Jun 30, 2005 at 16:40 -0500: JM Basicly a process will hang in either ffsfsn (fsync induces this JM write) or getblk (a read), and as far as I can find out, the io JM just never returns even though the underlying block device JM continues to work fine.. I know this is probably a stupid answer, but ... Have you upgraded the firmware on the card? We have a number of ICP cards and with the 2.39 firmware we can easily lockup the box with the behavior you explain with a simple buildworld. Upgrading the firmware to 2.44 solves the problem completely for us. Well, the problem is that it doesn't happen very often (only two systems it happened to once), i.e. not reproducable, and to make matters worse, we have 100+ systems in the field at client sites, so, w/o a definate YES this fixes it, we can't really go around upgrading firmware.. Plus, we have a lot of older cards, where the current firmware is 2.34 (though we are running on 2.32 for many of our cards)... so, we can't use the really new firmware... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is considered the best supported RAID controller for 5.x?
Patrick M. Hausen wrote this message on Sat, Jun 18, 2005 at 11:43 +0200: The subject says it all ... I'm looking a new server, and right now have built it around the SRCZCRX PCI-X 128MB, since I've had good luck with the Intel RAID controllers with 4.x, and I *really* like the storcon CLI utility ... but, with the move to 5.x, I'm wondering if there is something else I should be looking at, or is this still a good card to go with? IMHO it's the entire product line of ICP Vortex, now owned by Adaptec. These cards really rock. Battery backed up cache, RAID 1+0, driver maintained my company's engineers, yet in the stock FreeBSD kernel, curses based management utility to repair arrays without reboot, unattended rebuild if you exchange a broken disk with a brand new one, same interface to the host for _all_ products including SATA, ... Just works. Period. We use them for typo3.org, wetteronline.de uses them. I'm in no way affiliated with them, I just like the products. A lot ;-) We happen to be using them too, though we have had two hangs on 5.4-R when using these cards (Intel's SRCU31A actually), though we are still investigating the problem. Basicly a process will hang in either ffsfsn (fsync induces this write) or getblk (a read), and as far as I can find out, the io just never returns even though the underlying block device continues to work fine.. We didn't have any troubles under 4.x with the driver as long as you had v1.10 of sys/dev/iir/iir.c integrated... otherwise we had similar hangs... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RPCPROG_NFS: RPC: Port mapper failure - RPC: Unable to receive
Dominic Marks wrote this message on Thu, Jun 09, 2005 at 12:56 +0100: On Thursday 09 June 2005 12:42, Goran Gajic wrote: Hi, RPCPROG_NFS: RPC: Port mapper failure - RPC: Unable to receive (jmg: I cc'd you on the off chance you have not seen this already, another user identified your changes as related, but I have not tested this myself.) Yes, it seems that changes to the kernel (specifically kqueue?) broke NFS (and other things) in -STABLE. See these messages for related reports. could you try backing out uipc_socket.c v1.208.2.19? If it broke because of my commits, it would of been this one, though I'm puzzeled as to why it didn't break in -current... P.S. Could you teach your mailer not to cc -stable twice? (once as freebsd.org and again as www.freebsd.org) -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
nfs and kqueue udp sockets broken (now fixed!)
I broke NFS with the commits of 1.208.2.19 (RELENG_5) and 1.68.2.26 (RELENG_4) to src/sys/kern/uipc_socket.c, so, if you have either of those revisions, please upgrade. This bug is now fixed. It was broken for the last 2.5 days. Sorry for this disruption. Now back to your regularly scheduled programming. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libc_r kqueue fd leak
Ed Maste wrote this message on Tue, May 24, 2005 at 17:51 -0400: On Tue, May 24, 2005 at 01:36:48PM -0400, Ed Maste wrote: On Tue, May 24, 2005 at 12:59:07PM -0400, Ed Maste wrote: We discovered a kqueue leak when running one of our 4.x applications on FreeBSD 5.3 using the compat libc_r. It turns out it's caused by libc_r's close() failing. I've attached a patch which stops libc_r close() from bailing if fstat() returns an error. This fixes the kqueue leak. This logic would also have to make its way into the compat library via 4.x to fully resolve the issue. After a little more research it seems the kernel fix is already documented in threads/75795. Version 1.77 of kern_event.c changed kqueue_stat to just return ENXIO. We discovered the problem because each call in our app to getipnodebyname (and in turn the resolver) leaked one kqueue, which eventually used up all kernel memory and then caused a panic. I noticed that jmg originally did the kqueue locking work which removed kqueue_stat, hence the CC:. yes, the reason I made _stat return ENXIO is that _read and _write are not supported by kqueue, and so _stat provided useless information. When I added locking, it would only be reading a value that would immediately be able to be changed, making it informational at best.. You'd better spend your syscall calling kevent and getting a few events off the queue than trying to figure out how much work you have to do... (In one of my programs, I have code that dynamicly increases the number of kevent structs I pull off if I get the max..) After being pestered by ps, I have created a patch.. after a quick test that it compiles and runs, I'll commit it... Though libc_r depending upon _stat seems broken to me... Who knows what else doesn't implement _stat and can't be closed.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Manipulating disk cache (buf) settings
Sven Willenberger wrote this message on Mon, May 23, 2005 at 10:58 -0400: We are running a PostgreSQL server (8.0.3) on a dual opteron system with 8G of RAM. If I interpret top and vfs.hibufspace correctly (which show values of 215MB and 225771520 (which equals 215MB) respectively. My understanding from having searched the archives is that this is the value that is used by the system/kernel in determining how much disk data to cache. This is incorrect... FreeBSD merged the vm and buf systems a while back, so all of memory is used as a disk cache.. The buf cache is still used for filesystem meta data (and for pending writes of files, but those buf's reference the original page, not local storage)... Just as an experiment, on a quiet system do: dd if=/dev/zero of=somefile bs=1m count=2048 and then read it back in: dd if=somefile of=/dev/null bs=1m and watch systat or iostat and see if any of the file is read... You'll probably see that none of it is... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Manipulating disk cache (buf) settings
Vivek Khera wrote this message on Mon, May 23, 2005 at 17:17 -0400: On May 23, 2005, at 1:44 PM, John-Mark Gurney wrote: This is incorrect... FreeBSD merged the vm and buf systems a while back, so all of memory is used as a disk cache.. The buf cache is still used for filesystem meta data (and for pending writes of files, but those buf's reference the original page, not local storage)... Cool... So what would you recommend telling an application like Postgres what the cache size is? All of RAM? That seems unlikely given much of the ram is used for other things. Is there no upper bound in how much RAM will be used for the cache? I'm not familar host Postgres uses the cache number to change it's behavior, but I would say choose a responable amount of memory that you expect to regularly have available on the system... If you are only using it for db, and a few other small processes, 512meg less than ram is probably reasonable... The other way is to try a few different values and see how it impacts performance.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em and bge driver MPSAFE?
Mipam wrote this message on Wed, May 11, 2005 at 16:39 +0200: Perhaps lame to ask, But are the em and bge driver MPSAFE? I couldn't find notes about being mpsafe in the man pages of these drivers? I was about to point you to: http://www.freebsd.org/projects/busdma/ But realized that you probably wanted status on 5.x, and not HEAD... a quick look at the code shows that both em and bge are MPSAFE... I can tell because of no references to Giant or GIANT, and that it using XX_LOCK and has functions ending in _locked in them... Maybe we need to expand the busdma project to include which driver status for 5.x and HEAD? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mutex tty owned at ../../../kern/kern_event.c:1487
Dan Nelson wrote this message on Sat, Apr 23, 2005 at 22:52 -0500: In the last episode (Apr 23), John-Mark Gurney said: Dan Nelson wrote this message on Sat, Apr 23, 2005 at 12:28 -0500: Got the following on a 2004-04-21 -stable kernel: panic messages: --- panic: mutex tty owned at ../../../kern/kern_event.c:1487 cpuid = 0 I can whip up a patch if you want to try it (and can easily reproduce)... I tried repeating the panic (hitting ^C in an app partway through its startup routine), but it's not cooperating, unfortunately. it's a very tight race.. basicly a second character has to come in between the time the first one happens, and before the test for the PENDIN flag happens... most likely to occure over an ssh pty that has a program using kqueue.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mutex tty owned at ../../../kern/kern_event.c:1487
Dan Nelson wrote this message on Sat, Apr 23, 2005 at 12:28 -0500:
Got the following on a 2004-04-21 -stable kernel:
panic messages:
---
panic: mutex tty owned at ../../../kern/kern_event.c:1487
cpuid = 0
[...]
#0 doadump () at pcpu.h:159
#1 0xc05b44aa in boot (howto=260) at ../../../kern/kern_shutdown.c:410
#2 0xc05b4884 in panic (fmt=0xc07aed2c mutex %s owned at %s:%d) at
../../../kern/kern_shutdown.c:566
#3 0xc05aac23 in _mtx_assert (m=0xc383c910, what=0, file=0xc07acb39
../../../kern/kern_event.c, line=1487) at ../../../kern/kern_mutex.c:753
#4 0xc0596aad in knote (list=0xc383c880, hint=0, islocked=0) at
../../../kern/kern_event.c:1487
#5 0xc05eb699 in ttwakeup (tp=0xc383c800) at ../../../kern/tty.c:2374
#6 0xc05e83b4 in ttyinput (c=13, tp=0xc383c800) at ../../../kern/tty.c:601
#7 0xc05ea23c in ttypend (tp=0xc383c800) at ../../../kern/tty.c:1658
#8 0xc05e9c5b in ttnread (tp=0xc383c800) at ../../../kern/tty.c:1352
#9 0xc05e9b80 in filt_ttyread (kn=0xc2803374, hint=0) at
../../../kern/tty.c:1313
#10 0xc0596b3c in knote (list=0xc383c880, hint=0, islocked=0) at
../../../kern/kern_event.c:1504
#11 0xc05eb699 in ttwakeup (tp=0xc383c800) at ../../../kern/tty.c:2374
#12 0xc05e937b in ttioctl (tp=0xc383c800, cmd=2150396949, data=0xc39864c0,
flag=3) at ../../../kern/tty.c:1064
#13 0xc05ec6f5 in ttyioctl (dev=0x0, cmd=2150396949, data=0xc39864c0
\006\t, flag=3, td=0x0) at ../../../kern/tty.c:2917
#14 0xc05ef0f8 in ptyioctl (dev=0xc2bce300, cmd=2150396949, data=0xc39864c0
\006\t, flag=0, td=0x0) at ../../../kern/tty_pty.c:623
#15 0xc056da0c in spec_ioctl (ap=0xe97b7c00) at
../../../fs/specfs/spec_vnops.c:357
#16 0xc056d038 in spec_vnoperate (ap=0x0) at
../../../fs/specfs/spec_vnops.c:118
#17 0xc06233e4 in vn_ioctl (fp=0xc3968198, com=2150396949, data=0xc39864c0,
active_cred=0xc3a00a00, td=0xc3d05780) at vnode_if.h:503
#18 0xc05dbae8 in ioctl (td=0xc3d05780, uap=0xe97b7d14) at file.h:257
#19 0xc07535e0 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi
= 1, tf_esi = 1, tf_ebp = -1079060792, tf_isp = -377782924, tf_ebx =
674260420, tf_edx = 140677888, tf_ecx = -2144570347, tf_eax = 54, tf_trapno =
12, tf_err = 2, tf_eip = 673731391, tf_cs = 31, tf_eflags = 582, tf_esp =
-1079060884, tf_ss = 47}) at ../../../i386/i386/trap.c:1001
#20 0xc073e38f in Xint0x80_syscall () at ../../../i386/i386/exception.s:201
#21 0x002f in ?? ()
[garbage]
#48 0xc3585900 in ?? ()
#49 0xc05c6f90 in sched_switch (td=0x1, newtd=0x283065c4, flags=---Can't read
userspace from dump, or kernel process---
) at ../../../kern/sched_4bsd.c:881
gdbcom:2: Error in sourced command file:
Previous frame inner to this frame (corrupt stack?)
ok, how wonderful... we've recursed in the tty code... someone needs
to fix filt_ttyread so that it doesn't process characters... filt_ttyread
should be completely with out side effects, and simply return the
current state of the tty descriptor... (filt_ttyread gets called from
places where going off and doing lots of work is not good)...
in the back trace below, it tried to process characters, which then
tried to notify kqueue again, and lock the tty lock, which doesn't work...
One easy fix is to fix ttnread to not call ttypend on calls from
filt_ttyread via a flag...
I can whip up a patch if you want to try it (and can easily reproduce)...
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 1000baseTX?
Peter Jeremy wrote this message on Sat, Mar 05, 2005 at 22:56 +1100: On Fri, 2005-Mar-04 23:39:36 -0800, Doug White wrote: On Thu, 3 Mar 2005, Yoshiaki Kasahara wrote: In man pages, dmesg and ifconfig of FreeBSD5, GbE operation over twisted pair is mostly referred as '1000baseTX'. I guess most of them should be replaced by '1000baseT'. 1000baseTX and 1000baseT are different standard and they are not compatible (TX needs CAT6 cable and uses pairs in different way). Also 1000baseTX support is very rare yet. I'm sorry I'm not sure if some devices really support TX. Do you have any documentation to back up this claim? I'm not sure about the pairing but there are two distinct standards for gigabit ethernet over UTP. Try typing 1000base-t 1000base-tx differences (without the quotes) into Google. The interesting thing about that is that most sites talking about the differences say 1000base-T require CAT-5e cabling, though the IEEE standard says only CAT-5.. :) And also the IEEE standard makes no mention of 1000base-TX... So, I would say most modern cards are 1000base-T compatible, though making sure we don't futz with an older card's description will be difficult... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ucom and sio
Brandon Fosdick wrote this message on Sat, Jan 08, 2005 at 16:58 -0800: Daniel O'Connor wrote: Is it blocking waiting for carrier detect to come up? Try using the cuaNN device instead. The software in question worked fine using a cuaNN device until said device died. Somebody else mentioned that I could set the device to ignore the carrier detect signal. How do I do that? Is it a flag to tcsetattr() or some kind of ioctl? You can also do that on the lock and/or inital device... stty -f /dev/ttyd0.lock clocal -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to remote update 4.10 - 5.3?
Igor Pokrovsky wrote this message on Thu, Dec 30, 2004 at 20:36 +0300: That's not so bad. A reinstall means you can newfs your partitions as UFS2 filesystems, which wouldn't be the case if you upgraded 4.10 in-place. Are there any other advantages of UFS2 over UFS except maximum disk size? faster fsck times due to not all inodes are allocated at fs creation time... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem burning iso images
Warren Liddell wrote this message on Fri, Dec 31, 2004 at 07:14 +1000: next writeable LBA 0 writing from file 5.3-RELEASE-i386-miniinst.iso size 274400 KB written this track 274400 KB (100%) total 274400 KB next writeable LBA 137352 writing from stdin Every time i goto burn a iso filoe of onto CD it ends up getting stuck at the above part. any reasons why this may be happening ? It'd be useful to provide the command that you are using to get this problem... It sounds like you might have a - at the end of your command and it's trying to burn a track from stdin... if you hit ctrl-d, it'll burn an empty track and continue, though it'll be better to not try to burn stdin in the first place... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
