[HEADSUP] changes to cam_get_device() and cam_open_device()
As there was no objections, I am going to commit changes to cam_get_device() that remove the following features: - ignoring 'r' and 'n' at the start of device name - ignoring whitespace at end of device name - parsing and ignoring slice and partition names in a device name cam(3) manual page is going to be updated to reflect the changes. This would simplify the code and disambiguate its behavior. Non-rewound and character disk/SCSI devices has not been supported for quite a while now. Support for parsing partition/slice names is incomplete (e.g. GPT scheme is not supported) and of questionable usefulness. Full diff is here: http://people.freebsd.org/~avg/cam.diff If you know of any functionality or application that would be broken by this change please stop me ASAP. Also, if you have any other reason to object to the change please speak up before the change is committed. Thank you. -- Andriy Gapon ___ 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: ISDN4BSD removal (was: FreeBSD 6.4 and 8.0 EoLs coming soon)
Hello, On Thu, Oct 07, 2010 at 12:35:01PM +, Peter Much wrote: > Any clues, ideas, pointers, hints, ressources,... are greatly > welcomed!! Maybe you don't really want to hear this, but... ISDN is a dying technology. Any time soon you won't get ISDN termination by your telecom provider anymore. If at all, theyll deliver S0 in your home while doing VoIP from that little box on your wall. You've got 1.5yrs now to change your setup (as I understand we're talking about a small home setup, nothing very complex) to VoIP. This is technically not a very complex task and you can even transfer your phone number. You cannot only have an networked answering machine, but yould also connect with your notebook or an IP phone from nearly everywhere in the world. Not only to check your answering machine, but even make or take calls on your local number when needed. I did the same step several years ago and I didn't regret it for a single second. FreeBSD also offers plenty of VoIP software. So if the services your VoIP provider offers don't satisfy your needs you can even have your own complete telephony solution behind it which offers an own answering machine, selective call forwarding, VPN access, ... Give it a try first and when you get comfy then switch over and forget about ISDN at all. - Oliver -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | |Ich bin das Internet. Sowahr ich Gott helfe. | ___ 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 hang in zio->io_cv) with dd read
On Thu, Oct 07, 2010 at 09:28:22PM +0300, Andriy Gapon wrote: > on 07/10/2010 20:31 John Hay said the following: > > Oct 7 17:11:49 thumper1 kernel: mvsch23: EMPTY CRPB 30 (->0) 0 4000 > > Can you rule out hardware (or driver-level) problems? > E.g. by dd-ing to/from disk directly. > Doing that in parallel on the same and/or different disks. > Running any disk I/O benchmarks. Well, it might not be conclusive, but here is what I have done/tried: dd from a few select disks. They all do about 64MB/s and 900 interrupts per second. No kernel messages in dmesg or /var/log/messages. Typical command is: dd if=/dev/ada17 of=/dev/null bs=64k count=8 8 simultaneous dds from the 8 disks on a controller. I still get 64MB/s and 7000+ interrupts per second. No kernel messages. 6 simultaneous dds from a disk on each of the 6 controllers. I still get 64MB/s and 900+ interrupts per second per controller. No kernel messages. I made a small zfs raidz2 with 6 disks, one from each controller. dd to and from it with no problem. I made a small zfs raidz2 with 8 disks, all from one controller. dd to and from it at 190MB/s and 270MB/s, no problem. Bonnie++ finished without a problem. Next I made a zpool with 2 X raidz2 with 8 disks each. Each raidz2 on its own controller: zpool create -m none tst \ raidz2 ada0p1 ada1p1 ada2p1 ada3p1 ada4p1 ada5p1 ada6p1 ada7p1 \ raidz2 ada8p1 ada9p1 ada10p1 ada11p1 ada12p1 ada13p1 ada14p1 ada15p1 Creating a file with dd finished without a problem, about 245MB/s. # dd if=/dev/zero of=/export/tst.dd bs=64k count=16 16+0 records in 16+0 records out 1048576 bytes transferred in 42.732294 secs (245382567 bytes/sec) Reading from the file caused a hang again: # dd of=/dev/null if=/export/tst.dd bs=64k This message arrived in dmesg: mvsch15: EMPTY CRPB 13 (->14) 0 And a little later there was a lot more: mvsch15: Timeout on slot 1 mvsch15: iec 0200 sstat 0123 serr edma_s 1100 dma_c dma_s rs 0002 status 50 mvsch2: EMPTY CRPB 16 (->0) 2 4000 mvsch2: EMPTY CRPB 18 (->0) 1 4000 mvsch2: EMPTY CRPB 19 (->0) 2 4000 mvsch2: EMPTY CRPB 20 (->0) 3 4000 mvsch2: EMPTY CRPB 21 (->0) 0 4000 mvsch2: EMPTY CRPB 22 (->0) 1 4000 mvsch2: EMPTY CRPB 23 (->0) 2 4000 ... While this was happening, a dd from ada7p1 ran at normal speed, but from ada15p1 (which is on mvsch15) hanged for a while until there was a burst of mvsX interrupts and then finished without a further hickup. The original dd from tst.dd still have not finished. So it might be a driver problem, which only occur when pushed in a different than I could with my simultaneous dds to the raw partitions. If there are more tests that I can do, just say what. If someone wants a login to debug this, I can do it. John -- John Hay -- j...@meraka.csir.co.za / j...@freebsd.org ___ 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"
rs(1) damages data
Recently rs has adopted a habit of damaging data in long lines of input. This can easily be tested: # jot -s\ -b 01234567 1000 | rs 0 1 | grep -vxF 01234567 012345 67 012 34567 012345 67 012 34567 012345 67 012 34567 The jot command prints the string 01234567 a thousand times in a single row. The rs command is supposed to generate an automatic(0) number of rows with 1 column per row. I.e. every word stands in its own line. The grep filters all intact words, so everything that is printed, was damaged by rs. This has the look of a repetitive pattern to me, probably this happens at a fixed buffer boundary. > uname -a FreeBSD mobileKamikaze.norad 8.1-STABLE FreeBSD 8.1-STABLE #0: Mon Sep 6 17:08:51 CEST 2010 r...@mobilekamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510b-8 amd64 -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ 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: Serious zfs slowdown when mixed with another file system (ufs/msdosfs/etc.).
> Ok. But how stable (production ready) the FreeBSD-8-STABLE is? What is your > opinion? I am running 8-STABLE from 27th September on all our ptoduction machines (from webservers to database servers to the company mail server) and it is fine. I am going to update again over the next few days, as there are some ZFS fixes in which I want - and which may benifit you too - so I will be able to report back next week as to how a more recent version behaves. In general though, I have never had problems running STABLE on prodyction systems over the years. Of course what I do is to test it on a singlre machine before rolling it out (a leaf in a webfarm so if it goes down it wont affect the business) but it is usually fine. keep an eye on -STABLE mailing list though, as that is where problems arise. I watch that, and also the dailing commits, either here http://www.freshbsd.org/?branch=RELENG_8&project=freebsd&committer=&module=&q= or here http://www.secnetix.de/olli/FreeBSD/svnews/?p=stable/8 Just to see whats going into the tree relative to whats being discussed. It only takes a few minutes a dat to monitor the mailin lists and the commits, and the result is that we've been running STABLE for a very long time (close to a decade I suspect) with great success. -pete. ___ 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: Multiple zdevs in the root zpool?
On Fri, Oct 08, 2010 at 01:24:04AM +0300, Andriy Gapon wrote: > on 08/10/2010 00:35 Matthew Seaman said the following: > > On 07/10/2010 21:28:30, Andriy Gapon wrote: > >> on 07/10/2010 13:45 Matthew Seaman said the following: > >>> However, according to my understanding, if you want to boot from a > >>> zpool, you can only have one vdev in that pool. > >>> > >>> But what exactly does this mean? > >> > >> Yes, exactly, what does that mean? :) > >> Where did your understanding come from? > >> > > > > It was from reading posts like this: > > http://lists.freebsd.org/pipermail/freebsd-questions/2010-January/211677.html > > > > Plus the comments in > > cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c and > > sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c (grep for > > the words 'root pool') > > Hmm, it seems like a protection for limitations of OpenSolaris boot loader > that > slipped into our sources. > I am pretty sure that our boot code can boot such pools without problems. FreeBSD doesn't have OpenSolaris limitations when it comes to booting. You can boot from multi-vdev pools, from RAIDZ1, RAIDZ2, etc. There are some comments in the code that comes from OpenSolaris and suggests otherwise, but simply ignore them. There is also one change to be merged soon, that removes a check that prevents adding new vdevs when bootfs property is set (r212385). -- Pawel Jakub Dawidek http://www.wheelsystems.com p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpumgRFDzAQg.pgp Description: PGP signature
Re: ISDN4BSD removal (was: FreeBSD 6.4 and 8.0 EoLs coming soon)
This is straying a bit, but I think it is important: the only good measure of when a technology is too old, is when people (who use FreeBSD in this case) stop using it. On Fri, 08 Oct 2010 11:12:32 +0200 Oliver Brandmueller wrote: > Maybe you don't really want to hear this, but... > > ISDN is a dying technology. Any time soon you won't get ISDN termination > by your telecom provider anymore. If at all, theyll deliver S0 in your > home while doing VoIP from that little box on your wall. I don't know how it works in other countries, but here (in Norway) it works like this: yes - ISDN technology is dying. However, like all other technologies that major telcos have invested a lot in, its death is very slow. Extremely slow in fact. It could very well be that ISDN will live five or ten years still here, simply because it doesn't cost too much to maintain, and there is no new technology to push the dying ISDN over the edge off the cliff. Why is this? Well, telcos here are investing in mobile technologies for phones. They are _not_ interested in (and do not invest significant money in) things like VoIP. In fact, major telcos here doesn't invest significant money in fibre cables. They only put as much money into it as they need to keep the competition at bay. So who is investing in VoIP and fibre cables here? Answer: the ISP's that doesn't have any large investments in traditional telco cables. Another thing about VoIP calls: have they solved the "emergency call needs a location" problem? Here (again: in Norway) they are still working out how to solve this: if you call emergency services (police, fire department, etc.) from yout VoIP number; how do the emergency center locate you? I mean; how do they know that you are at home, and not at say, a cabin half across the country? With old landlines, there is no problem; it is always installed at an address. Just my point of view. -- Regards, Torfinn Ingolfsen ___ 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: ISDN4BSD removal
On 2010-10-08 18:12, Torfinn Ingolfsen wrote: Another thing about VoIP calls: have they solved the "emergency call needs a location" problem? Here (again: in Norway) they are still working out how to solve this: if you call emergency services (police, fire department, etc.) from yout VoIP number; how do the emergency center locate you? Ehm, you tell them? You have them on the phone. :) ___ 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: out of HDD space - zfs degraded
I noticed this is occurring on the siis driver. Silicon Image has, in my observations, had issues when any kind of port multiplication is occurring (either by the card itself or by hardware port multiplier that you purchase). I have timeouts on my drives for my Silicon Image based controller card if I use more than two ports (it was two eSATA and two internal SATA). If you search the mailing list other people have similar issues who use port multipliers. I've had good, brand new drives timeout randomly with this driver. ___ 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: Panic: attempted pmap_enter on 2MB page
Apologies for late response, wanted to check the code again. On 10/07/2010 10:03 AM, Alan Cox wrote: > Alan Cox wrote: > At a high-level, I agree with much of what you say. In particular, if > pmap_enter() is applied to a virtual address that is already mapped by a large > page, the reported panic could result. However, barring bugs, for example, in > memory allocation by the upper levels of the kernel, the panic inducing > situation shouldn't occur. Calls to malloc() of items larger than a page takes a turn through UMA and eventually ends up in kmem_malloc() via its page_alloc() routine. Kmem_malloc() in turn gets the pages from vm_page_alloc(), parks them in the kmem_object and maps them into the kernel_pmap in a loop callings pmap_enter() for each page. The assigned VA's are pulled from kmem_map. Pages acquired through vm_page_alloc() may be backed by a super page reservation and thus are eligible for auto-promotion. Calls to free() initially take a similar route, ending up on kmem_free() via UMAs page_free() routine. From there the call path is vm_map_remove(), vm_map_remove(), vm_map_delete() to pmap_remove(). This logic indicate, that from the kernel/vm perspective the malloc/free() pair will map/unmap pages as needed. However, the pmapper never unmaps these pages as far as I can tell. The call path is pmap_remove(), pmap_remove_pte() to pmap_unuse_pt() who ignores the removal because the VA >= VM_MAXUSER_ADDRESS. Without superpages this works fine because pmap_enter() allow replacement of already mapped pages, but it kasserts on replacing a page that falls within a super page. I showed one way for this to happen in my first post. The problem is the safety checks for promotion are tricked into promoting before all pages of an allocation are pmap_entered(). > At a lower-level, it appears that you are misinterpreting what pmap_unuse_pt() > does. It is not pmap_unuse_pt()'s responsibility to clear page table entries, > either for user-space page tables or the kernel page table. When a region of > the kernel virtual address space is deallocated, we do clear the kernel page > table entries. See, for example, pmap_remove_pte() (or pmap_qremove()). I probably messed up the terminology in my post, mixing kernel_map and kmem_map. Also I'm ignoring for the moment where the page table pages come from, just observing that for VAs above user space, the PTE entries are not cleared by calling pmap_remove(). pmap_qremove() does, but it's not used by free(). > This special handling of the kernel page table does create another special > case when we destroy a large page mapping within the kernel address space. We > have to reinsert into the kernel page table the old page table page (for small > page mappings) that was sitting idle while the kernel page table held a large > page mapping in its place. At the same time, all of the page table entries in > this page must be invalidated. This is handled by pmap_remove_pde(). I never understood why invalidation is required following promotion/demotions. The mapping does not change, attributes are the same, so unless the hardware can't cope with co-existing 4K and 2M TLB entries then invalidation seems unnecessary (A&D bits may need to be handled, but that might be quicker than sending IPIs to invalidate). > I'm curious to know more about you were doing when you encountered this > panic. Were you also using ISO images containing large MFS roots? I saw it during sysctls I wrote to dump certain large kernel structures. The MO was to allocate really big formatting buffer using malloc(). Truth be said, I did not see this on 2MB super pages, mine were much smaller and therefore more prone to this. Sincerely, Kurt A ___ 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: Panic: attempted pmap_enter on 2MB page
Kurt Alstrup wrote:
Apologies for late response, wanted to check the code again.
On 10/07/2010 10:03 AM, Alan Cox wrote:
Alan Cox wrote:
At a high-level, I agree with much of what you say. In particular, if
pmap_enter() is applied to a virtual address that is already mapped by a large
page, the reported panic could result. However, barring bugs, for example, in
memory allocation by the upper levels of the kernel, the panic inducing
situation shouldn't occur.
Calls to malloc() of items larger than a page takes a turn through UMA and
eventually ends up in kmem_malloc() via its page_alloc() routine.
Kmem_malloc() in turn gets the pages from vm_page_alloc(), parks them in
the kmem_object and maps them into the kernel_pmap in a loop callings
pmap_enter() for each page. The assigned VA's are pulled from kmem_map.
Pages acquired through vm_page_alloc() may be backed by a super page
reservation and thus are eligible for auto-promotion.
Calls to free() initially take a similar route, ending up on kmem_free()
via UMAs page_free() routine. From there the call path is vm_map_remove(),
vm_map_remove(), vm_map_delete() to pmap_remove().
This logic indicate, that from the kernel/vm perspective the malloc/free()
pair will map/unmap pages as needed. However, the pmapper never unmaps
these pages as far as I can tell. The call path is pmap_remove(),
pmap_remove_pte() to pmap_unuse_pt() who ignores the removal because the
VA >= VM_MAXUSER_ADDRESS.
No, consider:
static int
pmap_remove_pte(pmap_t pmap, pt_entry_t *ptq, vm_offset_t va,
pd_entry_t ptepde, vm_page_t *free)
{
pt_entry_t oldpte;
vm_page_t m;
PMAP_LOCK_ASSERT(pmap, MA_OWNED);
oldpte = pte_load_clear(ptq);
pte_load_clear() zeroes the PTE, regardless of whether it is a kernel or
user PTE.
I'm afraid that I need to catch an airplane. I'll follow up to the rest
of your message later.
Regards,
Alan
___
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: ISDN4BSD removal
On Friday 08 October 2010 12:22:40 pm Dimitry Andric wrote: > On 2010-10-08 18:12, Torfinn Ingolfsen wrote: > > Another thing about VoIP calls: have they solved the "emergency call > > needs a location" problem? Here (again: in Norway) they are still > > working out how to solve this: if you call emergency services (police, > > fire department, etc.) from yout VoIP number; how do the emergency > > center locate you? > > Ehm, you tell them? You have them on the phone. :) Um, could be a kid that dialed the phone, or someone may have lost consciousness. How can this still be a problem? Congres mandated that all phones have GPS, didn't they? ___ 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"
VirtualBox OpenSolaris guest
Does anybody know how to correct the audio driver problem of the opensolaris guest? The internet advice to run pfexec update_drv -a -i '"pci8086,2415"' audio810 is better than nothing, but the audio quality is absolutely miserable. It is clearly not the required audio driver. Therefore the flashplayer, i.e. the ***only reason*** why I've installed the opensolaris guest (following the advice of C. P. Ghost on the questions list), is useless:-( The other point is that the installation of additional repositories (needed for mplayer for example, I dislike totem) does not work either. My hope to find an interim solution for the flashplayer nightmare (while waiting for gnash) can be measured by the amount of hours I've spent to get flash - easily and long-term-wise - playing on FreeBSD, Ubuntu, PCBSD... I guess that FreeBSD will never be supported by Adobe. Thanks in advance for any help. Harald Weis ___ 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: VirtualBox OpenSolaris guest
On Fri, Oct 8, 2010 at 1:00 PM, Harald Weis wrote: > Does anybody know how to correct the audio driver problem of the > opensolaris guest? > The internet advice to run > pfexec update_drv -a -i '"pci8086,2415"' audio810 > > is better than nothing, but the audio quality is absolutely miserable. > It is clearly not the required audio driver. > Therefore the flashplayer, i.e. the ***only reason*** why I've installed > the opensolaris guest (following the advice of C. P. Ghost < > cpgh...@cordula.ws> > on the questions list), is useless:-( > http://www.freebsd.org/doc/handbook/desktop-browsers.html -- No need for that run around. Flash at least mostly works on FreeBSD. Has some stall issues but flashblock takes care of most of that issue. Works that way for me across multiple installs and versions of FreeBSD(7 & 8). FreeBSD 7 requires a bit more work with the linuxulator. (while waiting for gnash) > That's the funniest thing I've heard all week. -- Adam Vande More ___ 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: VirtualBox OpenSolaris guest
,--- You/Harald (Fri, 8 Oct 2010 20:00:46 +0200) * | My hope to find an interim solution for the flashplayer nightmare | (while waiting for gnash) can be measured by the amount of hours | I've spent to get flash - easily and long-term-wise - playing on FreeBSD, | Ubuntu, PCBSD... | | I guess that FreeBSD will never be supported by Adobe. Flash works beautifully for me on FreeBSD 8.1 in both Firefox 3.6 (use the instructions at http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/desktop-browsers.html) and in Opera (linux and native.) Is your problem "flash" or "audio" (i.e. can you play an mp3 file with mpg123, for example)? -- Alex -- alex-goncha...@comcast.net -- ___ 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: ISDN4BSD removal
Steven Friedrich writes: > On Friday 08 October 2010 12:22:40 pm Dimitry Andric wrote: >> On 2010-10-08 18:12, Torfinn Ingolfsen wrote: >> > Another thing about VoIP calls: have they solved the "emergency call >> > needs a location" problem? Here (again: in Norway) they are still >> > working out how to solve this: if you call emergency services (police, >> > fire department, etc.) from yout VoIP number; how do the emergency >> > center locate you? >> >> Ehm, you tell them? You have them on the phone. :) > > Um, could be a kid that dialed the phone, or someone may have lost > consciousness. > > How can this still be a problem? Congres mandated that all phones have GPS, > didn't they? No. Not even cell phones have to have GPS. For Internet-based telephony, the regulatory requirement involves customer cooperation, not technology. ___ 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: ISDN4BSD removal (was: FreeBSD 6.4 and 8.0 EoLs coming soon)
On 8 October 2010 18:12, Torfinn Ingolfsen wrote: [...] > I don't know how it works in other countries, but here (in Norway) it > works like this: yes - ISDN technology is dying. > However, like all other technologies that major telcos have invested a > lot in, its death is very slow. Extremely slow in fact. > > It could very well be that ISDN will live five or ten years still here, > simply because it doesn't cost too much to maintain, and there is no > new technology to push the dying ISDN over the edge off the cliff. I second that. Living in germany I feel that many people are even used to their good ol' analog phone lines. And since broadband here is called "DSL" we need phone lines anyway. So the only reason to call classic telephone services would be to use the freed frequency to extend the bandwith available to DSL. And I don't see that happen anytime soon. On the contrary, with all the investments in wireless technologies I think that ISDN will stay for several years. Personally I like having a good, solid backup when DSL goes down. And I don't trust VoIP enough to shut down my classic telephone lines. ___ 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: Enabling MCA causes system hangs
On Sunday, October 03, 2010 2:49:27 am Daniel O'Connor wrote: > > On 14/09/2010, at 16:49, Daniel O'Connor wrote: > >> So, you either have to disable one of them or upgrade to a more recent > >> version. > >> The version you need is r206183. The latest stable/8 would do, obviously. > > > > I'll try updating to stable/8 - I've been meaning to anyway. > > > > Just to find the spare time to do it :) > > I found some time, and now it seems to work fine. > > Thanks! :) > > I also wrapped http://ftp2.pl.freebsd.org/pub/FreeBSD/HEAD/src/sbin/mca/mca.c > in a script and run it every hour. > > Is there a periodic in current for it? IMO it would be handy to do so. That command is for ia64, not i386 and amd64. -- John Baldwin ___ 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: ISDN4BSD removal
On 10/8/2010 2:12 AM, Oliver Brandmueller wrote: ISDN is a dying technology. That sort of isn't relevant to the questions of: 1) Are there developers willing to support it, and 2) Are there users that want to use it. If both of those are true, then we need to do support it. Doug (tools, not policy) -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ ___ 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: ISDN4BSD removal
Or have they been superceded by voip stacks that abstract away the isdn layer? I would contend, at least in the US, ISDN is alive and well. Your basic smb softpbx installation is going to be talking to a digium card that is connected to a Basic/Primary Rate ISDN (B/PRI) or T-line. If the OP is using I4B to do voice data processing, perhaps he would be better served migrating to either freeswitch and/or asterisk ports? On 2010-10-08 12:27:56PM -0700, Doug Barton wrote: > On 10/8/2010 2:12 AM, Oliver Brandmueller wrote: > > ISDN is a dying technology. > > That sort of isn't relevant to the questions of: > 1) Are there developers willing to support it, and > 2) Are there users that want to use it. > > If both of those are true, then we need to do support it. > > > Doug (tools, not policy) > > -- > > Breadth of IT experience, and| Nothin' ever doesn't change, > depth of knowledge in the DNS. | but nothin' changes much. > Yours for the right price. :) |-- OK Go > http://SupersetSolutions.com/ > ___ > 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" -- === Peter C. Lai | Bard College at Simon's Rock Systems Administrator| 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 === ___ 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: ISDN4BSD removal
On 10/8/2010 12:37 PM, Peter C. Lai wrote: If the OP is using I4B to do voice data processing, perhaps he would be better served migrating to either freeswitch and/or asterisk ports? That's a policy decision. We don't do policy decisions, we do technology. I'll say it again, "Tools, not policy." -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ ___ 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: out of HDD space - zfs degraded
I noticed this is occurring on the siis driver. Silicon Image has, in my observations, had issues when any kind of port multiplication is occurring (either by the card itself or by hardware port multiplier that you purchase). I have timeouts on my drives for my Silicon Image based controller card if I use more than two ports (it was two eSATA and two internal SATA). If you search the mailing list other people have similar issues who use port multipliers. I've had good, brand new drives timeout randomly with this driver. ___ 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: out of HDD space - zfs degraded
On Fri, Oct 08, 2010 at 04:35:41PM -0400, Adam Stylinski wrote: > I noticed this is occurring on the siis driver. Silicon Image has, in my > observations, had issues when any kind of port multiplication is occurring > (either by the card itself or by hardware port multiplier that you > purchase). I have timeouts on my drives for my Silicon Image based > controller card if I use more than two ports (it was two eSATA and two > internal SATA). If you search the mailing list other people have similar > issues who use port multipliers. I've had good, brand new drives timeout > randomly with this driver. Off-topic (and normally I'd send this privately, but I think 5 Emails to the list of the same content is enough to warrant a list-based response): Your mailer is going crazy. I've received a total of *five* Emails from you on this matter, all with the same content, but all sent at different times and all contain different (unique) submission queue IDs. My client: 661 10/08 13:08 Adam Stylinski (0.7K) └─> 662 10/08 13:08 Adam Stylinski (0.7K) ├=> 663 10/08 13:08 Adam Stylinski (0.7K) ├=> 664 10/08 13:08 Adam Stylinski (0.7K) ├=> 665 10/08 16:35 Adam Stylinski (0.7K) └─> The SMTP Received: headers, indicating its your mail client or mail server which is sending duplicates to gmail. I should note your From: line for #665 differs from all the rest, as do the mail headers. #661 -- Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id D5B828FC15 for ; Fri, 8 Oct 2010 17:20:57 + (UTC) Received: by gyg4 with SMTP id 4so501275gyg.13 for ; Fri, 08 Oct 2010 10:20:36 -0700 (PDT) #662 -- Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1BB8FC1F for ; Fri, 8 Oct 2010 17:21:04 + (UTC) Received: by gyg4 with SMTP id 4so501362gyg.13 for ; Fri, 08 Oct 2010 10:20:56 -0700 (PDT) #663 -- Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id C2CE58FC18 for ; Fri, 8 Oct 2010 17:20:09 + (UTC) Received: by gwb15 with SMTP id 15so500347gwb.13 for ; Fri, 08 Oct 2010 10:20:09 -0700 (PDT) #664 -- Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2E9648FC15 for ; Fri, 8 Oct 2010 17:38:45 + (UTC) Received: by gxk8 with SMTP id 8so507502gxk.13 for ; Fri, 08 Oct 2010 10:38:45 -0700 (PDT) #665 -- Received: from mail-yw0-f54.google.com (209.85.213.54) by pod51000.outlook.com (10.6.4.250) with Microsoft SMTP Server (TLS) id 14.0.650.49; Fri, 8 Oct 2010 20:35:41 + Received: by ywh2 with SMTP id 2so118133ywh.13for ; Fri, 08 Oct 2010 13:35:41 -0700 (PDT) Please do something about this, as it's highly irritating. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: ISDN4BSD removal
On Fri, 08 Oct 2010 18:22:40 +0200 Dimitry Andric wrote: > On 2010-10-08 18:12, Torfinn Ingolfsen wrote: > > Another thing about VoIP calls: have they solved the "emergency call > > needs a location" problem? Here (again: in Norway) they are still > > working out how to solve this: if you call emergency services (police, > > fire department, etc.) from yout VoIP number; how do the emergency > > center locate you? > > Ehm, you tell them? You have them on the phone. :) If you are in a state to tell them, yes of course you do. However, the situtation might mean that you aren't very coherent at all. -- Torfinn ___ 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"
