ISDN4BSD removal (was: FreeBSD 6.4 and 8.0 EoLs coming soon)
aka Vadim Goncharov schrieb mit Datum Wed, 08 Sep 2010 04:31:46 +0700 in m2n.fbsd.stable: |You do not understand the problem. It is not in notices & volunteers, but |rather in the Project's policy - delete something which could still work. |Personally, I don't use ISDN, so didn't said anything that time, but now, Hi all, at this point I would like to speak up, because I am practically using ISDN4BSD. I just decided to upgrade to RELENG-8, and found out that I cannot. So now I have 1 1/2 years (until 7.3 EOL) to figure out a solution. I will not complain, because I think people here do an incredible good work, and the only very small thing I can contribute is occasional bug reports and sometimes patches. But what I want to say is: It is *NOT TRUE* that the I4B feature has become of limited usefulness today! I am using I4B as an answering machine for my phone-line, with the feature to monitor these calls and to download them as MP3 from anywhere in the world (could even be a web-interface, but I hadn't yet the time to write that). I don't want everybody to know my cellular nr; I don't want to (costly) forward calls to my cellular; but I want to be able to monitor and react on calls nevertheless! This is very easy and very comfortable - and currently I have no idea which other equipment could provide me with such functionality (if any would exist at all). And - my router is running anyway, it doesn't consume extra power when doing this - in fact, I think this is one of the most useful things one can do with a computer that is kept running all the time... So, I am sure my demand for this functionality will continue to exist for an indefinite time into the future, and in fact I am sad. To be honest, I am quite clueless now. Theoretically I do understand the problem with I4B. (Practically I do not understand it, because for me it has nothing to do with networking - I do only use the phone call monitoring/handling.) But staying with 7.3 will cut me off from other improvements/fixes, which I would much enjoy. Anyway, there is another open issue for me: my ISDN adapter card is ISA technology, so I will have to get a PCI type card as soon as I replace the mainboard of that system (which is imminent because it's too slow and too power-consuming - the ISDN being the main reason why I didnt do that already). But maybe, now I should look for some completely different approach? Any clues, ideas, pointers, hints, ressources,... are greatly welcomed!! rgds, PMc ___ 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/panic: short after rollback
aka Kip Macy schrieb mit Datum Fri, 12 Jun 2009 13:54:40 -0700 in m2n.fbsd.stable: |show sleepchain |show thread 100263 | |On Fri, Jun 12, 2009 at 6:56 AM, Andriy Gapon wrote: |> |> I did zfs rollback x...@yyy |> And then did ls on a directory in the rolled-back fs. |> panic: sleeping thread This is quite likely the same problem as I experience. And it is maybe also the same problem as in kern/137037 and kern/129148. It seems to show up in some different flavours, while the bottomline is this: do a rollback, and soon after (usually at the next filesystem-related action) the kernel has gone fishing. I experienced it first when doing a rollback of a mounted filesystem. It crashed right after the first try, and it did so reproducible. (Well, more or less reproducible - another day under similar circumstances it did not crash.) Then I started thinking, and came to the conclusion that a rollback of a mounted filesystem (with possibly open files) could easily bring a lot of things into an undefined state, and should not be something one wants to do normally. So maybe it is not supposed to work at all. Anyway, when trying this, I do either get the "sleeping thread" message (as above), or a panic from _sx_xlock() (as shown in my addendum to kern/137037, and in the addendum to kern/129148). So I started to do rollbacks on unmounted filesystems (quite an excessive amount of them), and while this seemed to work at first, later on the system failures reappeared. These system failures took various shapes - I experienced immediate resets without dump, and system hangs. When deliberately trying to reproduce that (after installing a kernel with debugging info and watching the console), I also captured a panic coming from _sx_xlock() - so it seems to be the same problem as without unmounting, only that it takes a couple of rollbacks (a dozen or more) to hit. Over all, there was never any data loss or persistent damage. So, I consider rollback still functional and safe to use, but I consider a system no longer production stable after doing a rollback. rgds, PMc ___ 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: 7.2-STABLE ZFS: mv: set flags (was: 00000000): Invalid argument
aka Peter Much schrieb mit Datum Wed, 22 Jul 2009 09:51:52 GMT in m2n.fbsd.stable: |After upgrading my system from 7.2-PRERELEASE to 7.2-STABLE (as |of last week), and accordingly upgrading my Pools from Version |6 to Version 13, I get this error when moving arbitrary files |between different ZFS filesystems. .. found my mistake: there are *two* tasks in the upgrade. Not only zfs pools need upgrade from version 6 to 13 (with command "zpool"), also the zfs filesystems need upgrade from version 1 to 3 (with command "zfs"). After doing both, the message is gone. rgds, PMc ___ 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"
7.2-STABLE ZFS: mv: set flags (was: 00000000): Invalid argument
Hi ZFS gurus! After upgrading my system from 7.2-PRERELEASE to 7.2-STABLE (as of last week), and accordingly upgrading my Pools from Version 6 to Version 13, I get this error when moving arbitrary files between different ZFS filesystems. While this seems not to do much harm (mv returns with 0), it is annoying. Does anybody know an explanation or fix, or is there some work in progress? rgds, PMc ___ 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: Can an app crash from a single TCP packet lost in transmission?
aka Chuck Swiger schrieb mit Datum Fri, 17 Jul 2009 13:49:10 -0700 in m2n.fbsd.stable: |On Jul 17, 2009, at 12:12 PM, Peter Much wrote: |[ ... ] |> One other thing did happen between 03:51 and 03:52 - the DSL |> internet connection did disconnect/reconnect and obtained a new |> IP adress. Afterwards, a script does flush and reload an ipfw table() |> with the new local adresses - and during this process one(!) packet |> of the database session was dropped. | |Well, there you go: having your IP change is certainly going to break |existing network connections; Uh, is that so? Maybe I wasnt clear enough: the failing database connection is a LOCALHOST-LOCALHOST connection - and it uses the (fixed) IP of one of the LAN interfaces, not the dynamic internet IP on the tun/PPP interface. Changing the IP on one interface while using another interface is, to all my knowledge, normal business. And even IF there were problem with that, then I would expect the connection to timeout and fail, I would NOT expect a memory leak to appear and drive the system out of swap within seconds. !I don't believe there is anything which |is going to move the existing connection state in a NAT translation |layer or whatever over to the new IP. Nay, that doesnt work. |Presumably you can obtain a |static IP and avoid such issues. I have a static internet IP on the machine, also, for HTTPS. I have lots of interfaces there. And I did run some tests in the meantime. The problem is in the PostgresQL library; it doesnt depend on a changed IP; - I only need to steal one packet out of the transmission, then the database client will grow to VSZ=1500GB and bigger. That's perfect reproduceable. The postgresQL is 8.2, rather old by now - but I really wonder that noone else did get into this during all the time. rgds, PMc ___ 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"
Can an app crash from a single TCP packet lost in transmission?
The first thing I noticed was that my nameserver had gone. I searched for the reason and found: >Jul 15 04:04:52 edge kernel: swap_pager_getswapspace(3): failed < ... hundreds more of these ... > >Jul 15 04:05:07 edge kernel: pid 47113 (named), uid 53, was killed: out of swap space That didn't make sense - the machine has enough swapspace. But since this did repeat every other night, I started logging ps output minutely. And so I found a postgres database backup going weird: 03:23 70 78433 78432 0 96 0 8220 4196 - R ??0:22.84 pg_dump -b < ... > 03:49 70 78433 78432 0 96 0 8220 4024 - R ?? 17:06.61 pg_dump -b 03:50 70 78433 78432 0 96 0 8220 4024 - R ?? 17:46.15 pg_dump -b 03:51 70 78433 78432 0 96 0 8220 4024 - R ?? 18:26.69 pg_dump -b 03:52 70 78433 78432 0 47 0 139292 57888 select S ?? 18:37.65 pg_dump -b 03:53 70 78433 78432 0 48 0 139292 57828 select S ?? 18:40.36 pg_dump -b 03:54 70 78433 78432 0 -20 0 401436 69092 swread DL?? 18:42.49 pg_dump -b 03:55 70 78433 78432 0 -20 0 401436 63232 swread DL?? 18:43.99 pg_dump -b That process starts with 8MB memory, and runs so for half an hour, then suddenly between 03:51 and 03:52 memory usage explodes. And in that night it did not run out of swap space - instead it gave an error message: >pg_dump: Error message from server: lost synchronization with server: > got message type "0", length 154143043 >pg_dump: The command was: COPY public.file (fileid, fileindex, jobid, > pathid, filenameid, markid, lstat, md5) TO stdout; But that database backup is at that time quite in the middle of dumping a db table containing lots of small records - there is no reason why a 154 MB "message" should be transferred between server and client while copying records of ~60 Bytes each. One other thing did happen between 03:51 and 03:52 - the DSL internet connection did disconnect/reconnect and obtained a new IP adress. Afterwards, a script does flush and reload an ipfw table() with the new local adresses - and during this process one(!) packet of the database session was dropped. I could verify that relation: every night when there were memory problems, few packets from the database backup were lost during the firewall reconfigure - in nights when no packets were lost, there were no memory problems. I will now change the firewall handling to get rid of that packet loss, but also, I need some refresh on how TCP works: I thought TCP would not be disturbed by a lost packet, but would automatically resend that packet until ACK received; and I thought this would happen below the application, so practically the application CANNOT go weird from a lost packet... Is there any reason why this would not be true on a localhost connection? rgds, PMc ___ 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: 7.2-PRE: switch virtual console drops crazy characters into X
! I'm also seeing the same issue, but I'm running a custom kernel. I've ! attached a diff from GENERIC. Okay, I send You my diff. Good luck with experimenting! Aeh, FYI: my graphics card identifies itself as Matrox Graphics, Inc. MGA G400/G450 rev 4 and the "device mgadrm" has something to do with that, I have forgotten what. That piece seems currently not to exist as a loadable module. rgds, PMc - cpu I486_CPU - cpu I586_CPU cpu I686_CPU - deviceaac - deviceaacp deviceadv - deviceadw - deviceage deviceagp - deviceaha - deviceahb - deviceahc - deviceahd - deviceaic - deviceale - deviceamd - deviceamr - devicean deviceapic - devicearcmsr - deviceasr deviceata deviceatadisk deviceatapicd - deviceatapifd - deviceatapist - deviceataraid - deviceath - deviceath_hal - deviceath_rate_sample deviceatkbd deviceatkbdc - deviceaue - deviceawi - deviceaxe - devicebce - devicebfe - devicebge devicebpf - devicebt - devicecardbus - devicecbb devicecd - devicecdce devicech - deviceciss devicecpufreq - devicecs - devicecue deviceda - devicedc - devicedcons - devicedcons_crom devicede - devicedpt + devicedrm deviceed deviceehci - deviceeisa - deviceem - deviceep - deviceet deviceether - deviceex devicefaith devicefdc - devicefe - devicefirewire devicefirmware - devicefwe - devicefwip devicefxp devicegif - devicehptiop - devicehptmv - devicehptrr - deviceida - deviceie - deviceigb - deviceiir - deviceips deviceisp - deviceixgb - devicejme - devicekbdmux - devicekue - devicele - devicelge deviceloop devicelpt devicemd - devicemfi + devicemgadrm devicemiibus - devicemlx - devicemly - devicempt - devicemsk - devicencv - devicenfe - devicenge + devicenmdm - devicensp deviceohci devicepass - devicepccard devicepci - devicepcn deviceplip devicepmtimer deviceppbus deviceppc deviceppi - deviceppp - devicepsm - devicepst devicepty - deviceral devicerandom - devicere devicerl - devicerue - devicerum devicesa - devicesbp devicesc devicescbus deviceses - devicesf devicesio - devicesis - devicesk - devicesl - devicesn + devicesnd_cmi + devicesnd_ess + devicesnd_sbc + devicesound - devicesplash - deviceste - devicestg - devicestge devicesym - deviceti - devicetl - devicetrm devicetun - devicetwa - devicetwe - devicetx - devicetxp - deviceuark - deviceuart - deviceubsa - deviceubser deviceucom - deviceuftdi deviceugen deviceuhci deviceuhid - deviceuipaq deviceukbd deviceulpt deviceumass deviceums deviceuplcom - deviceural deviceurio deviceusb deviceuscanner - deviceuslcom - deviceuvisor - deviceuvscom devicevga - devicevge - devicevr - devicevx - devicewb - devicewi - devicewlan - devicewlan_amrr - devicewlan_ccmp - devicewlan_scan_ap - devicewlan_scan_sta - devicewlan_tkip - devicewlan_wep - devicexe devicexl + ident D1R72V1 - ident GENERIC + machine i386 - makeoptions DEBUG=-g - options ADAPTIVE_GIANT - options AHC_REG_PRETTY_PRINT - options AHD_REG_PRETTY_PRINT - options AH_SUPPORT_AR5416 - options ATA_STATIC_ID - options AUDIT + options AUTO_EOI_1 options CD9660 options COMPAT_43TTY + options COMPAT_AOUT - options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options COMPAT_FREEBSD6 + options COMPAT_LINUX + options DDB + options DUMMYNET options FFS - options GEOM_LABEL - options GEOM_PART_GPT + options HZ=200 + options
7.2-PRE: switch virtual console drops crazy characters into X
Hi all, to make a long story short, I got trapped in the Xorg upgrade problems (concerning HAL etc.) that were widely reported during January. After reading thru the material I figured out that there are not much chances that somebody would take effort and fix these things for a 6.3 Release. So I decided to give it a try with the 7.2-PRERELASE. And, well, after recompiling all the stuff, the problems seem gone so far. Only one strange thing has appeared: Every time I switch from X to a virtual console and back, I get some characters dropped into my command-line in the X window, and have to delete them with the backspace key. These characters read: ^[[20~ Now this is exactly the escape sequence on the F9 key (where the X runs), if it were pressed without Ctrl-Alt. That shouldn't happen. Now the funny thing is: this does only happen when booting the GENERIC kernel. When I boot my normal custom made kernel, it does not happen. Now this is strange. Usually the GENERIC kernel should show the least unexpected behaviour. Alright, there are lots and lots of devices left out of my custom kernel, but I do not see anything that could have to do with VT switching. I do not quite understand it. But I am also not so much bored that I would start trying out options and building kernels so to find what makes this happen. So, if anyone experiences the similar thing, and is enough annoyed to do something about it, I will happily send a diff from my kernel configs. rgds, PMc ___ 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"
Rel 7 works better (was: "s/stable/broken/g")
Hi folks, hi Freddy, sorry, missed Your note last year this time. aka Freddie Cash schrieb mit Datum Wed, 26 Mar 2008 14:04:00 -0700 in m2n.fbsd.stable: |On March 22, 2008 01:01 pm Peter Much wrote: |> Both of them were running Release 5.5, and they were doing all that |> is needed, and I was perfectly happy with this. |> [...] |> So I upgraded the first computer to Release 6.3. The outcome was | |A safer (recommended?) upgrade process when crossing major versions (ie |5.x to 6.x) is to upgrade to the latest release of the "old" version, |then to the .0 release of the "new" version, then to the latest release |of the "new" version. | |So from 5.x to 5.5, then from 5.5 to 6.0, then from 6.0 to 6.3. | |The devs take great pains to make the transition from "latest X.x to Y.0" |simple and mostly fool-proof, and the transition from "Y.x to Y.z" simple |and mostly fool-proof. But there are no guarantees when going from X.x |to Y.z. Maybe its good idea to replay Your message just now, as it seems good advice. I'm just strolling by to tell that I went from 6.3 to 7.2 just now with my testmachine, and this time it was a really good experience so far. I have now only one strangeness, which I think not worth a bug report, but I would invite You to think about what that can be. I post a separate note with better subject for that. And yes, I did ignore the good advice again, but 7.2 isn't officially out for release yet, so there are no safety belts anyway. rgds, PMc ___ 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: "s/stable/broken/g"
! Try the rev. 1.24 of the devfs_rule.c. In fact, it is fixed by somewhat ! bigger patch that I inlined below. It is already in CURRENT and RELENG_7. Thanks, this is cool: it seems to work on Rel. 6.3. :) rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "s/stable/broken/g"
On Wed, Mar 26, 2008 at 10:06:04PM +0100, Kris Kennaway wrote: ! Software always has bugs, and it is a mistake to think that the "stable" ! designation does not mean "has no bugs". It's unfortunate that you have ! hit a couple of them, but please continue to work through the process of ! documenting them. Oh, don't worry, sure I do! I was just wondering where we are heading. I did not perceive this kind of problems the earlier upgrades (since Release 2) - sure there were problems with the new stuff, but not with the established things. And I do not worry if support for something is not happening or is dropped (due to lack of interest or ressources or whatever), but if already existing functionality just silently goes away with apparently nobody noticing, then I perceive it as a loss of one of the core values of a *nix-on-pc: that you do not need to buy new and fast hardware to get things done (you only need *reliable* hardware - and the newer one often is reliable only if built for servers; the consumer stuff is just getting WORSE.) ! With regards to your ethernet problems, old cards like ed do not get ! much testing thesedays because few people use them. Combined with the ! fact that ethernet problems are often specific to certain hardware ! models or revisions, you may be the only person to have tried this ! particular case in many years. Well, there are two reasons why I am using them: 1) if you place twisted-pair under the carpet, it will break after some months. On BNC cables i can walk for years, it does no harm. :) 2) It's true, i get a lovely dual if_fxp 10/100 64bit card on ebay for 1 euro, and it actually runs on a pentium2 - but i need a router then; and there what i get -at the consumer end- is so incredibly full of bugs, I will not rely on these! And I cannot fix them. :( ! By the same token, these problems are ! difficult to fix without a developer having access to the same problem ! hardware. You might consider offering to ship it to an interested ! developer if one can be found. I definitely will! The question is if a problem comes from an extravagance in one specific model of hardware (then it is not worth to put work into ancient hardware), or if there was a logical coding mistake during development within an existing codepiece that is now seldom used. The latter I would like to have fixed. And the other point is: I do not currently know how well people in less developed countries are supplied with suitable hardware - but I see them picking up on *nix - and I like that. :) rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "s/stable/broken/g"
On Wed, Mar 26, 2008 at 05:00:12PM -0400, John Baldwin wrote: ! Try this patch for de(4). Thanks fpr the reply. I'll try this patch at next reboot. ! You need to supply the panic details for the devfs ! one (I've used devfs rules w/o issue on lots of machines ! via /etc/devfs.conf). I have found, eh, not the solution but the problem. ;) This one: kern/89784 describes the same symptom and nearly the same backtrace. And it is still open, so this, well, just seems to exist. And, things being this way, I don't think there is need for me to do any more about it for now, as this does not really hurt and workaround is easy. Actually, the horror is not that something does not work - the horror is when, in an ambitiously complex setup which isn't fun to upgrade anyway, the next pagefault derisively grins at you, at the point when you would like to finish and go for a sleep, or a beer - and you know there are some good friends who have placed some web-stuff onto the machine, and you don't want to disappoint them... It's a situation where one enjoys reaching a good availability, but far from worth setting up an identical test environment (which would be the appropriate strategy to really avoid such surprizes). rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
"s/stable/broken/g"
Dear all, I have two computers. Both of them were running Release 5.5, and they were doing all that is needed, and I was perfectly happy with this. Now, as we know, security support for Release 5.5 will terminate during this spring, and as my computers are exposed to the Internet, this means that I MUST upgrade, even while I do not need or want anything from a higher release. So I upgraded the first computer to Release 6.3. The outcome was that on this computer, where Release 5 was running just fine for years, a Generic 6.3 kernel would just pagefault during boot. Nogo at all. I searched for the problem, and found it to be the network card - which is just a common standard de0 PCI card. Now, without network I cannot access the Internet, and if I do not access the Internet, then I do not need to upgrade! This is some kind of catch22. So I searched for the bug, I found something, I fixed it, and it helped. I published a description of the problem and the fix via sendbug (kern/120915) - but apparently nobody seems to be interested in a nonfunctional network on a so-called "production" release. Actually, I do not know what else I would have to do besides finding the bug, isolating the bug, creating a fix, using the fix and publishing the fix? So now I started to upgrade my second computer to Release 6.3. And when booting the Generic kernel, it does just pagefault quickly after booting is completed. I isolated the problem - it is the network card. This one is a well-known standard ed0 ISA card that has worked fine for 15 years now, and it pagefaults as soon as the first data is transferred. I replaced the card with one of a different brand (but also ed0), and the problem went away. So, the mere statistical evidence is this: when upgrading from release 5.5 to 6.3, 100% of the computers that did work fine with 5.5 do no longer run. I suppose the next thing I should do is some kind of reality check, to adjust my understanding of the words "stable", "production" and "upgrade". :-/ But the more severe aspect of the matter is, if this is a trend that will intensify with further upgrades, and if so, then what to do about it. "never change a running system" would be a good approach, if there were not the security issues. The other approach is to always buy new hardware. That is the Windows approach, and I do not like it. When a Pentium-II/350 is only 10% loaded, then why should one get a new computer for the job?? It just eats more power and creates ecohazard waste. :-( rgds, PMc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "s/stable/broken/g"
And the party continues... When starting my usual environment, there is already the next pagefault kernel panic! Tracking it down... it's the "type" keyword in devfs rules. According to the manpage, support for this was _not_ withdrawn. But actually, entering something like devfs rule apply type tape WHATEVER crashes the system. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
