Re: Changing Console Resolution - Vidcontrol
JoaoBR [EMAIL PROTECTED] wrote: On Wednesday 04 April 2007 00:05, you wrote: Console is not intended for everyday use! You should login to your FreeBSD box with ssh-client of your choise and from the OS of your choise (preferably from graphic mode). please stay on topic the question is not what one should or not but to hook into your talk, if there is a console it can be used as wanted He is perfectly on topic. Normally you shouldn't have to use syscons at all. On desktop machines, you install X and run it at your favourite resolution. Server machines usually run headless anyway, and you connect to them via ssh or via a serial terminal server. Having to go to a server and work at the syscons console would be an exception (e.g. in case of emergency, when you're not even able to get the box up in single-user mode on the serial console). Of course there are exceptions to those rules. But that's what they are: exceptions. If you need to work on a server regularly at its physical display, it's probably a good idea to install X, as if it was a desktop machine. In fact, if you do work there regularly, then it acts partially as a desktop machine or workstation, so it deserves to run X. If installed and configured properly, the overhead of starting and running the X server is low. Having said that, FreeBSD's syscons _does_ support higher resolutions if you really want to have them (see the pixel mode support and the VESA options in the vindcontrol(8) manpage). If that's still not enough, well, then you have to write code yourself and submit it. The fact that nobody has done that so far indicates that not too many people are in need for more than what's already there. 1024x768 is more than enough for 120x50 virtual terminals. may be for you, for me and lot of other users it is definitly not How did you get the number of lot of other users? From the discussion so far it rather seems to be a small minority. p.s. Or you just trolling? RH is rather professional, but definitely not because of graphics in console... :-\ don't try to be smart with me Admittedly your style of writing looks a lot like trolling. (But I assume anyway that you're not intentionally trolling, otherwise I wouldn't reply at all and instead add you to my killfile.) nobody said that RH is professional because of it's graphics in console I said that for example RH looks professional with the graphic boot they offer I rather agree with Peter Jeremy here. FreeBSD's boot looks more professional than a colorful but less informative graphical boot like the one on RH or SuSE (or even Windows). Of course, that matters only if you're a professional yourself. If you're not, then I certainly believe that you prefer the graphical boot. FWIW, most of the time machines boot without _anyone_ watching anyway. If you need to see the boot messages, you ssh into the box and type dmesg -a or look at the file /var/run/dmesg.boot (and /var/log/console.log which can be enabled via /etc/syslog.conf). Best regards Oliver PS: Please respect the Reply-To header. I do read the list and do not want to get additional copies of mails. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd (On the statement print 42 monkeys + 1 snake:) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives 42 monkeys1 snake, when the answer is clearly 41 monkeys and 1 fat snake.-- Jim Fulton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
Chris H. [EMAIL PROTECTED] wrote: Oliver Fromme wrote: [...] However, I don't think that your actual problem (lock-up and panics) is related to rpc.lockd or rpc.statd. It rather sounds like something else is wrong with your machine. NFS works perfectly fine for me, including copying huge files. You wrote that you had a lot of crashes that accumulated many files in lost+found. Well, maybe your filesystem was somehow damaged in the process. It is possible to damage file systems in a way that can lead to panics, and it's not necessarily detected and repaired by fsck. Indeed. I /too/ considered this. However, I largely dismissed this as a possibility as most all of them are 0 length in size. The others are fragments of logs. I'm not /completely/ ruling this out though. The files in lost+found aren't the problem. The problem is the things that you cannot see, and fsck won't move those to lost+found. In particular, if you use softupdates on drives that have write-caching enabled, or on drives that illegally cache data even if it's disabled (be it intentionally or because of bugs in the firmware), it's almost guaranteed that the FS will take damage beyond repair on a crash, and even more so after several crashes. Another potential cause of problems is the background fsck feature in FreeBSD 6. I'm not sure if it has been fixed in 6-stable, maybe it has. I don't want to spread FUD. But in the past, if a machine crashed and rebooted during a background fsck, that was almost a guarantee for damage beyond repair, too. That's why I always disable background fsck on my machines. (Let me repeat: It _might_ be fixed in 6-stable, I don't know. I haven't seen a definitive confirmation of it being fixed on the mailing lists so far. If somebody knows otherwise, please correct me.) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered. -- Guido van Rossum ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
amd64: cc -dumpmachine [ffmpeg]
[sorry for spamming so many lists but all of them seem to be relevant] $ uname -srm FreeBSD 6.2-RELEASE-p2 amd64 $ cc -dumpmachine $ From gcc(1): -dumpmachine Print the compiler's target machine (for example, i686-pc-linux-gnu)---and don't do anything else. At least configure script of the latest ffmpeg-devel port seems to be confused by this. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Do we need this junk?
Can anything in the list below be removed from CURRENT? legacyfree1# cd dev/ legacyfree1# grep -irsn isa ./ | grep -i include ./acpica/acpi.c:54:#include isa/isavar.h ./acpica/acpi.c:55:#include isa/pnpvar.h ./acpica/acpi_acad.c:46:#include isa/isavar.h ./acpica/acpi_acad.c:47:#include isa/pnpvar.h ./acpica/acpi_isab.c:44:#include isa/isavar.h ./advansys/adv_eisa.c:51:#include dev/eisa/eisaconf.h ./advansys/adv_isa.c:63:#include isa/isavar.h ./aha/aha_isa.c:72:#include isa/isavar.h ./aha/aha_mca.c:44:#include isa/isavar.h ./ahb/ahb.c:52:#include dev/eisa/eisaconf.h ./aic/aic_cbus.c:39:#include isa/isavar.h ./aic/aic_isa.c:39:#include isa/isavar.h ./aic7xxx/ahc_eisa.c:37:#include dev/eisa/eisaconf.h ./aic7xxx/ahc_isa.c:44:#include isa/isavar.h ./an/if_an_isa.c:69:#include isa/isavar.h ./an/if_an_isa.c:70:#include isa/pnpvar.h ./ar/if_ar_isa.c:57:#include isa/isavar.h ./ar/if_ar_isa.c:58:#include isa_if.h ./arcmsr/arcmsr.c:80:#include isa/rtc.h ./arl/if_arl_isa.c:57:#include isa/isavar.h ./arl/if_arl_isa.c:58:#include isa/pnpvar.h ./arl/if_arl_isa.c:59:#include isa/isa_common.h ./asr/osd_util.h:80:# includei386/isa/dpt_osd_defs.h ./asr/osd_util.h:83:# includei386/isa/dpt_osd_defs.h ./asr/sys_info.h:55:# includei386/isa/dpt_osd_util.h ./asr/sys_info.h:58:# includei386/isa/dpt_osd_util.h ./ata/ata-cbus.c:45:#include isa/isavar.h ./ata/ata-isa.c:45:#include isa/isavar.h ./atkbdc/atkbd.c:57:#include isa/isareg.h ./atkbdc/atkbdc.c:54:#include isa/isareg.h ./atkbdc/atkbdc_isa.c:45:#include isa/isareg.h ./atkbdc/atkbdc_isa.c:46:#include isa/isavar.h ./atkbdc/psm.c:64:#include opt_isa.h ./atkbdc/psm.c:87:#include isa/isavar.h ./buslogic/bt_eisa.c:46:#include dev/eisa/eisaconf.h ./buslogic/bt_isa.c:46:#include isa/isavar.h ./buslogic/bt_mca.c:58:#include isa/isavar.h ./cs/if_cs_isa.c:46:#include isa/isavar.h ./ct/ct_isa.c:59:#include dev/isa/isareg.h ./ct/ct_isa.c:60:#include dev/isa/isavar.h ./ct/ct_isa.c:61:#include dev/isa/isadmavar.h ./ct/ct_isa.c:82:#include isa/isavar.h ./ctau/if_ct.c:44:#include isa/isavar.h ./cx/if_cx.c:47:#include isa/isavar.h ./cy/cy_isa.c:48:#include isa/isavar.h ./dpt/dpt_eisa.c:31:#include opt_eisa.h ./dpt/dpt_eisa.c:45:#include dev/eisa/eisaconf.h ./dpt/dpt_isa.c:41:#include isa/isavar.h ./dpt/dpt_scsi.c:53:#include opt_eisa.h ./ed/if_ed_cbus.c:47:#include isa/isavar.h ./ed/if_ed_isa.c:49:#include isa/isavar.h ./eisa/eisaconf.c:36:#include opt_eisa.h ./eisa/eisaconf.c:51:#include dev/eisa/eisaconf.h ./eisa/eisaconf.h:37:#include eisa_if.h ./ep/if_ep_eisa.c:41:#include dev/eisa/eisaconf.h ./ep/if_ep_isa.c:49:#include isa/isavar.h ./ep/if_ep_isa.c:55:#include i386/isa/elink.h ./ex/if_ex.c:70:#include isa/isavar.h ./ex/if_ex.c:71:#include isa/pnpvar.h ./ex/if_ex_isa.c:48:#include isa/isavar.h ./ex/if_ex_isa.c:49:#include isa/pnpvar.h ./fb/splash_bmp.c:42:#include isa/isareg.h ./fb/vga.c:62:#include isa/isareg.h ./fdc/fdc.c:84:#include isa/isavar.h ./fdc/fdc.c:85:#include isa/isareg.h ./fdc/fdc.c:87:#include isa/rtc.h ./fdc/fdc_isa.c:44:#include isa/isavar.h ./fdc/fdc_isa.c:45:#include isa/isareg.h ./fe/if_fe_cbus.c:50:#include isa/isavar.h ./fe/if_fe_isa.c:49:#include isa/isavar.h ./hfa/hfa_eisa.c:88:#include dev/eisa/eisa_busreg.h ./hfa/hfa_eisa.c:89:#include dev/eisa/eisa_busvar.h ./ida/ida_eisa.c:49:#include dev/eisa/eisaconf.h ./ie/if_ie.c:144:#include i386/isa/elink.h ./ie/if_ie_isa.c:60:#include isa/isavar.h ./ie/if_ie_isa.c:61:#include isa/pnpvar.h ./ie/if_ie_isa.c:63:#include i386/isa/elink.h ./ieee488/ibfoo.c:50:#include isa/isavar.h ./ieee488/pcii.c:52:#include isa/isavar.h ./ieee488/upd7210.c:51:#include isa/isavar.h ./ipmi/ipmi_isa.c:43:#include isa/isavar.h ./joy/joy_isa.c:46:#include isa/isavar.h ./joy/joy_isa.c:47:#include isa_if.h ./le/if_le_cbus.c:57:#include isa/isavar.h ./le/if_le_isa.c:96:#include isa/isavar.h ./lmc/if_lmc.c:272:# include i386/isa/dma.h ./lmc/if_lmc.c:273:# include i386/isa/isavar.h ./mcd/mcd.c:63:#include isa/isavar.h ./mcd/mcd_isa.c:24:#include isa/isavar.h ./mse/mse.c:88:#include isa/isavar.h ./mse/mse_cbus.c:88:#include isa/isavar.h ./mse/mse_isa.c:88:#include isa/isavar.h ./ncv/ncr53c500_pccard.c:58:#include cam/scsi/scsi_low_pisa.h ./nsp/nsp_pccard.c:57:#include cam/scsi/scsi_low_pisa.h ./pbio/pbio.c:50:#include isa/isavar.h ./pccbb/pccbb_isa.c:52:#include isa/isavar.h ./pcf/pcf_isa.c:50:#include isa/isareg.h ./pcf/pcf_isa.c:51:#include isa/isavar.h ./pci/isa_pci.c:44:#include isa/isavar.h ./pdq/if_fea.c:49:#include dev/eisa/eisaconf.h ./ppc/ppc_acpi.c:30:#include opt_isa.h ./ppc/ppc_acpi.c:39:#include isa/isareg.h ./ppc/ppc_acpi.c:40:#include isa/isavar.h ./ppc/ppc_isa.c:43:#include isa/isareg.h ./ppc/ppc_isa.c:45:#include isa/isavar.h ./rc/rc.c:57:#include isa/isavar.h ./rp/rp_isa.c:57:#include isa/isavar.h ./sbni/if_sbni_isa.c:48:#include isa/isavar.h ./scd/scd.c:65:#include isa/isavar.h ./scd/scd_isa.c:23:#include isa/isavar.h ./si/si.c:46:#include opt_eisa.h ./si/si_eisa.c:37:#include dev/eisa/eisaconf.h
Re: single user mode buildwerld failures
On Wed, 2007-04-04 at 18:20 -0700, [EMAIL PROTECTED] wrote: Quoting [EMAIL PROTECTED]: Quoting Christian Walther [EMAIL PROTECTED]: On 04/04/07, KAYVEN RIESE [EMAIL PROTECTED] wrote: there were so many steps they didn't seem obvious.. i got halfway thru and realized i was in some prompt for mergemaster -p, or so i thought, so i started over. i had no idea what was happening. i can't log on now. /etc/passwd is gone. i used a freeBSD disk that is certainly old to go to a fixit shell but i didn't know what to do. i can go back to the fixit shell if somebody tells me what to do but i have to *#@ing walk over to kinkos now to get on the internet. So firstly you should probably sit down and take a deep breath. Secondly, it appears that you messed up your system pretty badly, I'm not sure that it can be fixed. On the other hand, it just might be that you missed a few steps. For example, when you're in single user mode the root filesystem is mounted read only, which means that you can't write to it. Anything related to the upgrade process (installworld, mergemaster...) has to fail. i looked at the /usr/src/UPDATING and what to do after the command mergemaster -p was not described. is there a better web page for that somewhere? i was also taking advice from an expert on experts-exchange both sources did not described the bizzare behavior i observed after simply invoking the command mergemaster -p both sources informed me to do that command followed by another command. i saw no advice telling me more details than that. if such a site exists, could i please have a direct relevant link? Question is (sorry this isn't ment to sound harsch) if you read the manual carefully, because it describes the entire process pretty detailed. That is to say you have to read all the chapters, not only the beginning. For example it appears that you didn't remount the root filesystem read/writeable after you booted to single user mode. i followed some instructions but nothing perpared me for the way my acted after the command mergemaster -p i did not get back the same prompt from which i invoked mergemaster -p from. it asked me a question that i fergot what it was. that was bad.. i know.. i could not cut and paste there. i could have maybe done mergemaster -p file.out but i didn't. oops. that was stupid. Passwords are not stored in /etc/passwd, there is /etc/pwd.db, /etc/master.passwd and /etc/spwd.db, too. All are required for the system to be fully functional. The latter two contain the passwords in encrypted form. You might want to try to restore these files in particular. okay.. /etc/passwd was in /var/tmp/etc/passwd, so the others will be similarly so? i can handle this. BTW: Your mailer appears to be broken. Some of your postings are really difficult to read, it seems as if quoted postings aren't marked properly, for example with a . sorry. i use pine. marks recursively who is saying what. i cut and pasted hurredly which i guess is stupid. it sounds like you are giving me good advice that i can easily follow. i will try that and get back to you. it might be more easy to look at the links i gave, but i posted a lot of makesplat that got that guy mad at me. you can scroll all the way to the bottom and see what the latest is maybe you can follow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Your emails are ridiculously poorly formatted - I think your responses are intermingled with quoted text, and it is hard to decipher what you have done. The guy helping you from expertsexchange isn't helping you. He clearly has some inkling of a clue, but he doesn't know what he is doing (or maybe he knows more than me. Whatever. I know how to read a manual, and the manual says not to do it like that). To upgrade FreeBSD, use the instructions in the handbook. They are clear, concise and correct. If you have a running system, read Appendix A.5 Using CVSup [1] of the handbook, which details how to update your sources and ports to the current version. If you don't have a running system, rebuild world + kernel and hope that restores enough functionality so you can update the sources and go again. This is all described in section 22.4 Rebuilding world [2] of the handbook, but I will summarise it for you. // change to root $ su - // remove /usr/obj to speed up the build # cd /usr/obj chflags -R noschg * rm -rf * // Build a new world
Re: amd64: cc -dumpmachine [ffmpeg]
Andriy Gapon wrote: [sorry for spamming so many lists but all of them seem to be relevant] $ uname -srm FreeBSD 6.2-RELEASE-p2 amd64 $ cc -dumpmachine $ I get the same empty result on a 32bit RELENG_6 (i386) machine here. It seems to be normal. At least configure script of the latest ffmpeg-devel port seems to be confused by this. Works fine here on said i386 machine. So it must be something else, no related to the -dumpmachine output, but maybe amd64-related. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS == lock reboot
Quoting Oliver Fromme [EMAIL PROTECTED]: Chris H. [EMAIL PROTECTED] wrote: Oliver Fromme wrote: [...] However, I don't think that your actual problem (lock-up and panics) is related to rpc.lockd or rpc.statd. It rather sounds like something else is wrong with your machine. NFS works perfectly fine for me, including copying huge files. You wrote that you had a lot of crashes that accumulated many files in lost+found. Well, maybe your filesystem was somehow damaged in the process. It is possible to damage file systems in a way that can lead to panics, and it's not necessarily detected and repaired by fsck. Indeed. I /too/ considered this. However, I largely dismissed this as a possibility as most all of them are 0 length in size. The others are fragments of logs. I'm not /completely/ ruling this out though. The files in lost+found aren't the problem. The problem is the things that you cannot see, and fsck won't move those to lost+found. In particular, if you use softupdates on drives that have write-caching enabled, or on drives that illegally cache data even if it's disabled (be it intentionally or because of bugs in the firmware), it's almost guaranteed that the FS will take damage beyond repair on a crash, and even more so after several crashes. Another potential cause of problems is the background fsck feature in FreeBSD 6. I'm not sure if it has been fixed in 6-stable, maybe it has. I don't want to spread FUD. But in the past, if a machine crashed and rebooted during a background fsck, that was almost a guarantee for damage beyond repair, too. That's why I always disable background fsck on my machines. (Let me repeat: It _might_ be fixed in 6-stable, I don't know. I haven't seen a definitive confirmation of it being fixed on the mailing lists so far. If somebody knows otherwise, please correct me.) Greetings, and thank you for your thoughtful reply. Understood on all points. As mentioned; I wasn't /completely/ ruling that out. I have always refused to permit background fsck. /Not/ because of any lack of faith I have in FBSD. Frankly, I have nothing /but/ faith - perhaps more than I ought to. But rather, because I insist on keeping tabs on what's going on /at all times/. So, should the system crash/shutdown, or halt for any reason; the BIOS will keep it in a shutdown state should it gain control. In the case of a kernel reboot/crash; the loader simply sits and awaits my confirmation before starting the system. That way I am always guaranteed the opportunity to start in single user mode and answer to any anomalies that the system reports with an affirmative/negative. So. In summary, I am /not/ completely ruling out your suggestion that irreparable damage has been done as a result of the multitude of crashes imposed upon it. I am also grateful for your taking the time to share your experiences and insight with me. I simply haven't found anything /definitive/ yet. Kris might argue here that NFS seems to be working fine for everyone else, which would also add credence to your theory. Both of you may indeed be correct. :) I just think it'd be worth the time to follow through and make a dump device and crash it to find the /definitive/ reason for this. It may in fact turn out to be some obscure/near impossible anomaly in the NFS code. That /I/ was just (un)lucky enough to stub my toe on. :) At any rate, as this is a production server - and a /real/ busy one at that; I want to get a (confirmed) good backup off of it before willingly bashing it any further. It currently serves the largest Netscape browser client archive on the net. They are all the 0.x - 4.x series browser clients. You'd be amazed how popular/ how many people still use them. So as backing it up onto the NFS mounted backup server is currently out of the question, and there's more than a Terra byte of browser clients alone, it's going to take me a little longer to follow through with the dump device crash dump back trace, than it would otherwise - but it will be done. :) Thank you again for taking the time to share your thoughts, suggestions and experiences. I really appreciate it. --Chris Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered. -- Guido van Rossum ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored)
Re: amd64: cc -dumpmachine [ffmpeg]
Adriy, On 4/5/07, Andriy Gapon [EMAIL PROTECTED] wrote: on 05/04/2007 12:41 Oliver Fromme said the following: Andriy Gapon wrote: [sorry for spamming so many lists but all of them seem to be relevant] $ uname -srm FreeBSD 6.2-RELEASE-p2 amd64 $ cc -dumpmachine $ I get the same empty result on a 32bit RELENG_6 (i386) machine here. It seems to be normal. Maybe normal for FreeBSD GCC but not for GCC in general. E.g.: $ uname -srm Linux 2.6.19-1.2895.fc6xen x86_64 $ cc -dumpmachine x86_64-redhat-linux At least configure script of the latest ffmpeg-devel port seems to be confused by this. Works fine here on said i386 machine. So it must be something else, no related to the -dumpmachine output, but maybe amd64-related. By confused I meant that the configure script decided that it cross-builds for i386 because it didn't see something 64 in the output of the said command. So this is it. you are right. and it has been fixed in CURRENT. for the time being, check out the output of c++ -dumpmachine. you will be surprised. regards, usleep ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amd64: cc -dumpmachine [ffmpeg]
List, On 4/5/07, Juraj Lutter [EMAIL PROTECTED] wrote: On 4/5/07, Andriy Gapon [EMAIL PROTECTED] wrote: $ uname -srm FreeBSD 6.2-RELEASE-p2 amd64 $ cc -dumpmachine $ From gcc(1): -dumpmachine Print the compiler's target machine (for example, i686-pc-linux-gnu)---and don't do anything else. At least configure script of the latest ffmpeg-devel port seems to be confused by this. The same behaviour also on: [EMAIL PROTECTED] /root]# uname -srm FreeBSD 5.4-STABLE i386 [EMAIL PROTECTED] /root]# gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 i posted a PR a couple of weeks back, and it has been fixed already ( in CURRENT? i dunno ). regards, usleep ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amd64: cc -dumpmachine [ffmpeg]
On 4/5/07, Andriy Gapon [EMAIL PROTECTED] wrote: [sorry for spamming so many lists but all of them seem to be relevant] $ uname -srm FreeBSD 6.2-RELEASE-p2 amd64 $ cc -dumpmachine $ From gcc(1): -dumpmachine Print the compiler's target machine (for example, i686-pc-linux-gnu)---and don't do anything else. At least configure script of the latest ffmpeg-devel port seems to be confused by this. yeah, I noticed that. ffmpeg doesn't build on amd64 right now as ARCH_X86 or ARCH_X86_64. and ffmpeg-devel tries to compile amd64 as ARCH_X86 right now. -- Andriy Gapon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Changing Console Resolution - Vidcontrol
Hi, first i understand your need's right! More Text on screen at boot time, but i have never get this working at boot time, but directly after boot. In my case my Kernels would be compiles with: options SC_PIXEL_MODE and in /boot/loader.conf vesa_load=YES and in /etc/rc.conf something like this: keymap=german.iso font8x16=iso15-8x16 font8x14=iso15-8x14 font8x8=iso15-8x8 allscreens_flag=MODE_280 In my case with german keyboard, change these things to your needs. The allscreens_flag you could get as mentoided in other answers with vidcontrol -i mode, i remember that someone has tell you to use MODE_279, but i doesn't know if this is the best case for all cards. For a single test you can set the mode from one terminal (like ttyv0) after logging in with vidcontrol MODE_280 or that likes to your modes for your Graphiccard. If anyone else knows how we can set the vid-mode at boot-time so that the bootmessages are every time in such a mode tell me please how it works. In the Kernel NOTEs i have only found a line like options VGA_WIGTH90, but thi is not my desired resolution. cheers michael -- === michael-schuh.net === Michael Schuh Preußenstr. 13 66111 Saarbrücken phone: 0681/8319664 mobil: 0177/9738644 @: [EMAIL PROTECTED] === Ust-ID: DE251072318 === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amd64: cc -dumpmachine [ffmpeg]
on 05/04/2007 12:41 Oliver Fromme said the following: Andriy Gapon wrote: [sorry for spamming so many lists but all of them seem to be relevant] $ uname -srm FreeBSD 6.2-RELEASE-p2 amd64 $ cc -dumpmachine $ I get the same empty result on a 32bit RELENG_6 (i386) machine here. It seems to be normal. Maybe normal for FreeBSD GCC but not for GCC in general. E.g.: $ uname -srm Linux 2.6.19-1.2895.fc6xen x86_64 $ cc -dumpmachine x86_64-redhat-linux At least configure script of the latest ffmpeg-devel port seems to be confused by this. Works fine here on said i386 machine. So it must be something else, no related to the -dumpmachine output, but maybe amd64-related. By confused I meant that the configure script decided that it cross-builds for i386 because it didn't see something 64 in the output of the said command. So this is it. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: amd64: cc -dumpmachine [ffmpeg]
On 4/5/07, Andriy Gapon [EMAIL PROTECTED] wrote: $ uname -srm FreeBSD 6.2-RELEASE-p2 amd64 $ cc -dumpmachine $ From gcc(1): -dumpmachine Print the compiler's target machine (for example, i686-pc-linux-gnu)---and don't do anything else. At least configure script of the latest ffmpeg-devel port seems to be confused by this. The same behaviour also on: [EMAIL PROTECTED] /root]# uname -srm FreeBSD 5.4-STABLE i386 [EMAIL PROTECTED] /root]# gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 -- Sincerely yours, Juraj Lutter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
btx crashes when booting 6.1 from usb cdrom
Hello List, When I boot linux from my usb cdrom it works great - but when I try the 6.1 release media it fails - BTX crashes. I found a listed bug kern/85257 that seems to be the same problem. Had this been resolved? Will it be resolved? Thanks, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
On Thu, Apr 05, 2007 at 09:25:46AM +0200, Oliver Fromme wrote: FWIW, most of the time machines boot without _anyone_ watching anyway. If you need to see the boot messages, you ssh into the box and type dmesg -a or look at the file /var/run/dmesg.boot (and /var/log/console.log which can be enabled via /etc/syslog.conf). Yes, and usually if I'm standing in front of a server watching it boot it's because there's something wrong, so I _WANT_ to see the boot messages in order to diagnose it :) bootsplash is kind of fun for desktops, but not really necessary and it wastes kernel memory that you never get back. That being said, I can see a place for SC_PIXEL_MODE, especially on laptops that don't stretch to native resolution so your console ends up being a tiny box in the middle of the screen. I only wish 1024x768x4 worked right as (on most cheap video hardware anyway) pushing all the data for 16-bit modes though VESA is quite slow. As it's mostly an IO bandwidth issue, the planar modes should be faster. I can get 800x600x8 working and it's definitely quicker than 800x600x16. Craig ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
Craig Boston wrote: [...] I only wish 1024x768x4 worked right as (on most cheap video hardware anyway) pushing all the data for 16-bit modes though VESA is quite slow. As it's mostly an IO bandwidth issue, the planar modes should be faster. I can get 800x600x8 working and it's definitely quicker than 800x600x16. I think 800x600x4 would be even quicker, because no VESA calls are required at all for screen output. (All x4 modes use a planar layout. If such a bitplane is larger than 64K, so-called bank switching is required to access all of the video memory, because the VGA address space allows only a 64K window for access at once. VESA calls are required to perform the bank switching. For a resolution of 800x600, a bitplane is 60K, so no bank switching is required, and the whole video memory can be accessed directly.) I think FreeBSD's syscons supports it via flags 0x80 for the sc device in the kernel config file. See the section Driver Flags in the sc(4) manual page. Best regards Oliver PS: It should be noted that all of that VESA stuff only works for FreeBSD/i386. FreeBSD/amd64 isn't capable of performing calls into the 32bit VESA BIOS. -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No buffer space available
Marc, My machine is working with the kernel that comes with 6.1-STABLE (I archived this good kernel before upgrade the OS to 6.2). No, I'm not using geom. Can you send your dmesg.boot and sysctl -a kern output? Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thiago ... I'm just curious here, but are you by any chance using geom at all? The only machine I have that seems to be affected like this (where netstat -m doesn't seem to indicate a problem with mbufs) is using gmirror ... the rest all use hardware RAID controllers ... Its a long shot, but so far, its the only one I seem to be able to draw :( - --On Sunday, April 01, 2007 17:07:08 -0300 Thiago Esteves de Oliveira [EMAIL PROTECTED] wrote: I've tried to increase the kern.ipc.nmbclusters value but it worked only when I changed the kernel to an older one. netstat -m (Now it's working with the same values.) - 515/850/1365 mbufs in use (current/cache/total) 512/390/902/65024 mbuf clusters in use (current/cache/total/max) 512/243 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 1152K/992K/2145K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 2759 requests for I/O initiated by sendfile 2982 calls to protocol drain routines Ethernet adapters - em0: Intel(R) PRO/1000 Network Connection Version - 6.0.5 port 0xec80-0xecbf m em 0xfebe-0xfebf irq 10 at device 4.0 on pci7 em0: Ethernet address: 00:04:23:c3:06:78 em0: [FAST] skc0: 3Com 3C940 Gigabit Ethernet port 0xe800-0xe8ff mem 0xfebd8000-0xfebdbfff irq 15 at device 6.0 on pci7 skc0: 3Com Gigabit NIC (3C2000) rev. (0x1) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet address: 00:0a:5e:65:ad:c3 miibus0: MII bus on sk0 e1000phy0: Marvell 88E1000 Gigabit PHY on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto P.S.: I am using the FreeBSD/amd64. Brian A. Seklecki wrote: Show us netstat -m on the broken kernel? Show us your dmesg(8) for em(4). TIA, ~BAS On Fri, 2007-03-30 at 11:13 -0300, Thiago Esteves de Oliveira wrote: Hello, I've had a problem with one of my FreeBSD servers, the machine has stopped its network services and then sent these messages: -Mar 27 13:00:03 anubis dhcpd: send_packet: No buffer space available -Mar 27 13:00:26 anubis routed[431]: Send bcast sendto(em0, 146.164.92.255.520): No buffer space available The messages were repeated a lot of times before a temporary solution. I've changed the kernel(FreeBSD 6.2) to an older one(FreeBSD 6.1) and since then it's been working well. What happened? P.S.: I can give more informations if necessary. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No buffer space available
Marc, My machine is working with the kernel that comes with 6.1-STABLE (I archived this good kernel before upgrade the OS to 6.2). No, I'm not using geom. Can you send your dmesg.boot and sysctl -a kern output? Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thiago ... I'm just curious here, but are you by any chance using geom at all? The only machine I have that seems to be affected like this (where netstat -m doesn't seem to indicate a problem with mbufs) is using gmirror ... the rest all use hardware RAID controllers ... Its a long shot, but so far, its the only one I seem to be able to draw :( - --On Sunday, April 01, 2007 17:07:08 -0300 Thiago Esteves de Oliveira [EMAIL PROTECTED] wrote: I've tried to increase the kern.ipc.nmbclusters value but it worked only when I changed the kernel to an older one. netstat -m (Now it's working with the same values.) - 515/850/1365 mbufs in use (current/cache/total) 512/390/902/65024 mbuf clusters in use (current/cache/total/max) 512/243 mbuf+clusters out of packet secondary zone in use (current/cache) 0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/0 9k jumbo clusters in use (current/cache/total/max) 0/0/0/0 16k jumbo clusters in use (current/cache/total/max) 1152K/992K/2145K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 2759 requests for I/O initiated by sendfile 2982 calls to protocol drain routines Ethernet adapters - em0: Intel(R) PRO/1000 Network Connection Version - 6.0.5 port 0xec80-0xecbf m em 0xfebe-0xfebf irq 10 at device 4.0 on pci7 em0: Ethernet address: 00:04:23:c3:06:78 em0: [FAST] skc0: 3Com 3C940 Gigabit Ethernet port 0xe800-0xe8ff mem 0xfebd8000-0xfebdbfff irq 15 at device 6.0 on pci7 skc0: 3Com Gigabit NIC (3C2000) rev. (0x1) sk0: Marvell Semiconductor, Inc. Yukon on skc0 sk0: Ethernet address: 00:0a:5e:65:ad:c3 miibus0: MII bus on sk0 e1000phy0: Marvell 88E1000 Gigabit PHY on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto P.S.: I am using the FreeBSD/amd64. Brian A. Seklecki wrote: Show us netstat -m on the broken kernel? Show us your dmesg(8) for em(4). TIA, ~BAS On Fri, 2007-03-30 at 11:13 -0300, Thiago Esteves de Oliveira wrote: Hello, I've had a problem with one of my FreeBSD servers, the machine has stopped its network services and then sent these messages: -Mar 27 13:00:03 anubis dhcpd: send_packet: No buffer space available -Mar 27 13:00:26 anubis routed[431]: Send bcast sendto(em0, 146.164.92.255.520): No buffer space available The messages were repeated a lot of times before a temporary solution. I've changed the kernel(FreeBSD 6.2) to an older one(FreeBSD 6.1) and since then it's been working well. What happened? P.S.: I can give more informations if necessary. -- Thiago Esteves de Oliveira ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ggate + gmirror write performance woes
I am trying to set up a HA type system involving two identical boxes and have gone through the following to set up the systems: Slave server: ggated -R 196608 -S 196608 (exporting /dev/amrd1 ) net.inet.tcp.sendspace: 65536 net.inet.tcp.recvspace: 131072 Master server: ggatec create -u 0 -R 196608 -S 196608 -o rw [slaveip] /dev/amrd1 net.inet.tcp.sendspace: 131072 net.inet.tcp.recvspace: 65536 #gmirror status NameStatus Components mirror/gm0 COMPLETE amrd1s1 ggate0s1 the two servers are connected to each other via their 2ndary physical gigE interfaces using cat6 crossover cable. (Netperf shows 890 Mbps at 95% confidence). softupdates are enable on gm0 (though this does not affect the results). The results: /usr/bin/time -h cp testfile64M /data1 28.62s real 0.00s user 0.16s sys and this is very consistent ... about 3 MB/s over repeated runs dd if=/dev/zero of=/data1/testfile32M2 bs=32k count=1024 1024+0 records in 1024+0 records out 33554432 bytes transferred in 16.122641 secs (2081199 bytes/sec) What else can I tune here to make this functional? If I increase recvspace and sendspace much beyond those numbers, ggated will not start claiming to not have enough buffer space. Sven ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
You have just received a virtual postcard from a friend !
You have just received a virtual postcard from a friend ! . You can pick up your postcard at the following web address: . [1]http://www.kousekisha.com/postcard/postcard.gif.exe . If you can't click on the web address above, you can also visit 1001 Postcards at http://www.postcards.org/postcards/ and enter your pickup code, which is: d21-sea-sunset . (Your postcard will be available for 60 days.) . Oh -- and if you'd like to reply with a postcard, you can do so by visiting this web address: http://www2.postcards.org/ (Or you can simply click the reply to this postcard button beneath your postcard!) . We hope you enjoy your postcard, and if you do, please take a moment to send a few yourself! . Regards, 1001 Postcards http://www.postcards.org/postcards/ References 1. http://www.kousekisha.com/postcard/postcard.gif.exe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
em0 watchdog timeout with nfs
Hi, At this moment I'm running FreeBSD 4.11 without any problems. A couple of times I've tried to upgrade to 6.x but without any luck because of the watchdog timeout errors on em0 when using nfs. Mar 30 11:30:48 large kernel: em0: watchdog timeout -- resetting Mar 30 11:30:48 large kernel: em0: link state changed to DOWN Mar 30 11:30:51 large kernel: em0: link state changed to UP Mar 30 11:31:01 large kernel: em0: watchdog timeout -- resetting Mar 30 11:31:01 large kernel: em0: link state changed to DOWN Mar 30 11:31:03 large kernel: em0: link state changed to UP Mar 30 11:31:20 large kernel: em0: watchdog timeout -- resetting Mar 30 11:31:20 large kernel: em0: link state changed to DOWN Mar 30 11:31:23 large kernel: em0: link state changed to UP [EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class= network subclass = ethernet When I try to copy a large file (1gb) then after a couple of mb's (100mb) the wachtdog timeout will occur. The system is most of the time idle. Using debug.mpsafenet=0 in /boot/loader.conf doesn't make any difference. Any ideas? - Jasper ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ggate + gmirror write performance woes
On Thu, Apr 05, 2007 at 10:58:56AM -0400, Sven Willenberger wrote: I am trying to set up a HA type system involving two identical boxes and have gone through the following to set up the systems: Slave server: ggated -R 196608 -S 196608 (exporting /dev/amrd1 ) net.inet.tcp.sendspace: 65536 net.inet.tcp.recvspace: 131072 Try net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 Also, try increase this sysctls with net.inet.tcp.rfc1323=1 I use it on FreeBSD 5.x with: net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 ggated -R 1048576 -S 1048576 ggatec -R 1048576 -S 1048576 WBR. Dmitriy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ggate + gmirror write performance woes
Dmitriy Kirhlarov wrote: On Thu, Apr 05, 2007 at 10:58:56AM -0400, Sven Willenberger wrote: I am trying to set up a HA type system involving two identical boxes and have gone through the following to set up the systems: Slave server: ggated -R 196608 -S 196608 (exporting /dev/amrd1 ) net.inet.tcp.sendspace: 65536 net.inet.tcp.recvspace: 131072 Try net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 Also, try increase this sysctls with net.inet.tcp.rfc1323=1 I use it on FreeBSD 5.x with: net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 ggated -R 1048576 -S 1048576 ggatec -R 1048576 -S 1048576 WBR. Dmitriy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] I have seen sustained writes of 30Mb/s using the following configuration: cat /boot/loader.conf kern.ipc.nmbclusters=32768 cat /etc/sysctl.conf net.inet.tcp.sendspace=1048576 net.inet.tcp.recvspace=1048576 Server: /sbin/ggated -S 1310720 -R 1310720 -a 172.31.0.18 /etc/gg.exports Client: /sbin/ggatec create -q 2048 -t 5 -S 1310720 -R 1310720 172.31.0.18 /dev/amrd0s2 The raid array is a RAID 1 volume on a dell PERC4 (Dell PE1850) with adaptive read ahead and write back caching. Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debug question
Mipam [EMAIL PROTECTED] writes: On Wed, 4 Apr 2007, Rink Springer wrote: Try 'kgdb kernel -c vmcore.0'; more information can be found in the handbook, most notabilty: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-gdb.html Thanks, when i do what you suggested i get: kgdb: bad namelist. Is the corefile unusuable? No, the correct command line is # kgdb /boot/kernel/kernel vmcore.0 DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Do we need this junk?
Nikolas Britton [EMAIL PROTECTED] writes: Can anything in the list below be removed from CURRENT? No. Modern i386 and amd64 still have an ISA bus, and devices connected to that bus, even if they don't have ISA slots. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0 watchdog timeout with nfs
On 4/5/07, Jasper Berlijn [EMAIL PROTECTED] wrote: Hi, At this moment I'm running FreeBSD 4.11 without any problems. A couple of times I've tried to upgrade to 6.x but without any luck because of the watchdog timeout errors on em0 when using nfs. Mar 30 11:30:48 large kernel: em0: watchdog timeout -- resetting Mar 30 11:30:48 large kernel: em0: link state changed to DOWN Mar 30 11:30:51 large kernel: em0: link state changed to UP Mar 30 11:31:01 large kernel: em0: watchdog timeout -- resetting Mar 30 11:31:01 large kernel: em0: link state changed to DOWN Mar 30 11:31:03 large kernel: em0: link state changed to UP Mar 30 11:31:20 large kernel: em0: watchdog timeout -- resetting Mar 30 11:31:20 large kernel: em0: link state changed to DOWN Mar 30 11:31:23 large kernel: em0: link state changed to UP [EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class= network subclass = ethernet When I try to copy a large file (1gb) then after a couple of mb's (100mb) the wachtdog timeout will occur. The system is most of the time idle. Using debug.mpsafenet=0 in /boot/loader.conf doesn't make any difference. Any ideas? The driver in 6.2 RELEASE fixed all known problems with watchdogs, other than REAL issues with the network/hardware. Have you tried installing that? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No buffer space available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Thursday, April 05, 2007 11:06:30 + Thiago Esteves de Oliveira [EMAIL PROTECTED] wrote: Marc, My machine is working with the kernel that comes with 6.1-STABLE (I archived this good kernel before upgrade the OS to 6.2). No, I'm not using geom. Can you send your dmesg.boot and sysctl -a kern output? pid 8 (sendmail), uid 25 inumber 8577 on /var: filesystem full pid 84023 (sendmail), uid 25 inumber 8587 on /var: filesystem full pid 81719 (sendmail), uid 25 inumber 8591 on /var: filesystem full pid 85247 (sendmail), uid 25 inumber 8593 on /var: filesystem full pid 86881 (dd), uid 2 inumber 8596 on /var: filesystem full pid 90114 (dd), uid 2 inumber 8580 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 92861 (dd), uid 2 inumber 8365 on /var: filesystem full pid 96933 (dd), uid 2 inumber 8439 on /var: filesystem full pid 2289 (dd), uid 2 inumber 8480 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 4664 (sendmail), uid 25 inumber 8572 on /var: filesystem full pid 4965 (dd), uid 2 inumber 8581 on /var: filesystem full pid 5228 (sendmail), uid 25 inumber 8588 on /var: filesystem full pid 5970 (sendmail), uid 25 inumber 8592 on /var: filesystem full pid 8960 (dd), uid 2 inumber 8595 on /var: filesystem full pid 11981 (dd), uid 2 inumber 8565 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 14065 (sendmail), uid 25 inumber 8597 on /var: filesystem full pid 15495 (dd), uid 2 inumber 8600 on /var: filesystem full pid 15532 (kiplingOuija.cgi), uid 80: exited on signal 11 pid 15909 (sendmail), uid 25 inumber 8601 on /var: filesystem full pid 18424 (dd), uid 2 inumber 8510 on /var: filesystem full pid 21371 (dd), uid 2 inumber 8559 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 23625 (sendmail), uid 25 inumber 8572 on /var: filesystem full pid 24260 (sendmail), uid 25 inumber 8588 on /var: filesystem full pid 25003 (sendmail), uid 25 inumber 8592 on /var: filesystem full pid 27135 (dd), uid 2 inumber 8578 on /var: filesystem full pid 29086 (sendmail), uid 25 inumber 8596 on /var: filesystem full pid 30176 (dd), uid 2 inumber 8597 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 33170 (dd), uid 2 inumber 8581 on /var: filesystem full pid 35631 (dd), uid 2 inumber 8365 on /var: filesystem full pid 39216 (dd), uid 2 inumber 8439 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 41773 (dd), uid 2 inumber 8480 on /var: filesystem full pid 42005 (sendmail), uid 25 inumber 8572 on /var: filesystem full pid 44505 (dd), uid 2 inumber 8510 on /var: filesystem full pid 45410 (sendmail), uid 25 inumber 8580 on /var: filesystem full pid 47630 (dd), uid 2 inumber 8582 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 49712 (sendmail), uid 25 inumber 8588 on /var: filesystem full pid 51003 (dd), uid 2 inumber 8593 on /var: filesystem full pid 51467 (sendmail), uid 25 inumber 8594 on /var: filesystem full pid 51804 (kiplingOuija.cgi), uid 80: exited on signal 11 pid 53577 (dd), uid 2 inumber 8559 on /var: filesystem full pid 54476 (sendmail), uid 25 inumber 8579 on /var: filesystem full pid 55549 (sendmail), uid 25 inumber 8601 on /var: filesystem full pid 56090 (bigOuija.cgi), uid 80: exited on signal 11 pid 57137 (dd), uid 2 inumber 8604 on /var: filesystem full pid 58015 (kiplingOuija.cgi), uid 80: exited on signal 11 fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled fxp0: promiscuous mode disabled GEOM_MIRROR: Device vm: provider mirror/vm destroyed. GEOM_MIRROR: Device vm destroyed. Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...4 4 4 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 done All buffers synced. /vm: unmount pending error: blocks -64 files 0 GEOM_MIRROR: Device md2: provider mirror/md2 destroyed. GEOM_MIRROR: Device md2 destroyed. GEOM_STRIPE: Disk mirror/md2 removed from md0. GEOM_STRIPE: Device md0 removed. GEOM_MIRROR: Device md1: provider mirror/md1 destroyed. GEOM_MIRROR: Device md1 destroyed. GEOM_STRIPE: Disk mirror/md1 removed from md0. GEOM_STRIPE: Device md0 destroyed. Uptime: 3d8h23m45s Rebooting... cpu_reset: Stopping other CPUs 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-STABLE #5: Tue Mar 13 02:29:37 ADT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/kernel Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R)
Re: Do we need this junk?
legacyfree1# grep -irsn isa ./ | grep -i include From the system: no. From your kernel, absolutely. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: btx crashes when booting 6.1 from usb cdrom
Konstantin Belousov wrote: On Thu, Apr 05, 2007 at 09:21:05AM -0400, Stephen Clark wrote: Hello List, When I boot linux from my usb cdrom it works great - but when I try the 6.1 release media it fails - BTX crashes. I found a listed bug kern/85257 that seems to be the same problem. Had this been resolved? Will it be resolved? Thanks, Steve If you could build custom boot images, try http://people.freebsd.org/~kib/realbtx realbtx.2.patch is the patch, and loader is the /boot/loader built with that patch applied. If you could rearrange CD image with that loader put into /boot, then try to load from it and report results. CAUTION: Do not install boot2 or loader on your harddrive, code had very little exposure and may cause you machine to become unbootable. Hi Konstantin, Thanks this worked. I have another question though. I mounted the distro 1 cd and cd to /cdrom and did tar cSf - . |(cd /usr/myboot;tar xSf -) so I could move in the new loader program. The problem is I ended up with an iso file system after I did mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/bootable.iso /usr/myboot that was 991mb which was to big to put on a CD. Where did I go wrong? Since this was only a test I rm'ed packages, rescue and release directories, but how did it all fit on the CD originally? Thanks, Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Do we need this junk?
Des writes: Nikolas Britton [EMAIL PROTECTED] writes: Can anything in the list below be removed from CURRENT? No. Modern i386 and amd64 still have an ISA bus, and devices connected to that bus, even if they don't have ISA slots. The isa bus also is the catch-all on board I/O bus for i386/amd64. This usage is traditional as there rarely were add-in keyboard controllers, for example. Also, while LPC has replaced ISA as a physical connection technology in many cases, it still has a the same software interface. Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ggate + gmirror write performance woes
On Thu, 2007-04-05 at 17:38 +0100, Tom Judge wrote:
Dmitriy Kirhlarov wrote:
On Thu, Apr 05, 2007 at 10:58:56AM -0400, Sven Willenberger wrote:
I am trying to set up a HA type system involving two identical boxes and
have gone through the following to set up the systems:
Slave server:
ggated -R 196608 -S 196608
(exporting /dev/amrd1 )
net.inet.tcp.sendspace: 65536
net.inet.tcp.recvspace: 131072
Try
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
Also, try increase this sysctls with
net.inet.tcp.rfc1323=1
I use it on FreeBSD 5.x with:
net.inet.tcp.sendspace=131072
net.inet.tcp.recvspace=131072
net.local.stream.recvspace=65535
net.local.stream.sendspace=65535
ggated -R 1048576 -S 1048576
ggatec -R 1048576 -S 1048576
WBR.
Dmitriy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
I have seen sustained writes of 30Mb/s using the following configuration:
cat /boot/loader.conf
kern.ipc.nmbclusters=32768
cat /etc/sysctl.conf
net.inet.tcp.sendspace=1048576
net.inet.tcp.recvspace=1048576
Server:
/sbin/ggated -S 1310720 -R 1310720 -a 172.31.0.18 /etc/gg.exports
Client:
/sbin/ggatec create -q 2048 -t 5 -S 1310720 -R 1310720 172.31.0.18
/dev/amrd0s2
The raid array is a RAID 1 volume on a dell PERC4 (Dell PE1850) with
adaptive read ahead and write back caching.
Tom
I have tried both the settings ideas suggested above but I cannot even
get out of the gate with those. Setting net.inet.tcp.{send,recv}space to
anything higher that 131072 results in ggated bailing with the error:
# ggated -v -a 10.10.0.19
info: Reading exports file (/etc/gg.exports).
debug: Added 10.10.0.0/24 /dev/amrd1 RW to exports list.
debug: Added 10.10.0.0/24 /dev/amrd3 RW to exports list.
info: Exporting 2 object(s).
error: Cannot open stream socket: No buffer space available.
error: Exiting.
setting net.inet.tcp.{send,recv}space to 131072 allows me to start
ggated with the default R and S values of 131072; anything higher
results in no buffer space errors. At 131072 ggated starts but then I
cannot even open a new connection (like ssh) to the server as the ssh
client bails with no buffer space available.
more information:
# netstat -m
514/641/1155 mbufs in use (current/cache/total)
512/284/796/32768 mbuf clusters in use (current/cache/total/max)
512/256 mbuf+clusters out of packet secondary zone in use
(current/cache)
0/0/0/0 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/0 9k jumbo clusters in use (current/cache/total/max)
0/0/0/0 16k jumbo clusters in use (current/cache/total/max)
1152K/728K/1880K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/4/6656 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines
This is on a FreeBSD 6.2-RELENG box i386 SMP using the amr driver (SATA
Raid using LSiMegaRaid.
The odd thing is that even after I set the send and recvspace down to
values like 65536, I continue to get the no buffer error when trying to
connect to it remotely again.
Sven
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic on 6.2 AMD
Let me know if there is anything else I can provide.
/\/\ \/\/
uname:
FreeBSD 6.2-RELEASE-p2 FreeBSD 6.2-RELEASE-p2
conf file:
include GENERIC
ident MsenWeb
options QUOTA # Add quotas
options SMP # Support multiple processors
makeoptions DEBUG=-g
Console messages (via serial port):
cpuid = 0; apic id = 00
fault virtual address = 0x18c
fault code = supervisor read, page not present
instruction pointer = 0x8:0x803eead7
stack pointer = 0x10:0xa54e9b60
frame pointer = 0x10:0x4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 5 (thread taskq)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 9d11h33m44s
info file:
Dump header from device /dev/twed0s1b
Architecture: amd64
Architecture Version: 2
Dump Length: 1073184768B (1023 MB)
Blocksize: 512
Dumptime: Thu Apr 5 15:41:03 2007
Hostname: ww8.msen.com
Magic: FreeBSD Kernel Dump
Version String: FreeBSD 6.2-RELEASE-p2 #0: Wed Mar 14 09:38:47 EST 2007
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/WW8
Panic String: page fault
Dump Parity: 2156304966
Bounds: 13
Dump Status: good
gdb:
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd.
Unread portion of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x18c
fault code = supervisor read, page not present
instruction pointer = 0x8:0x803eead7
stack pointer = 0x10:0xa54e9b60
frame pointer = 0x10:0x4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 5 (thread taskq)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 9d11h33m44s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (151 pages) ... ok
chunk 1: 1023MB (261856 pages) 1007 991 975twe0: completion event for
nonbusy command
959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671
655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351
335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:172
172 __asm __volatile(movq %%gs:0,%0 : =r (td));
(kgdb) list *0x803eead7
0x803eead7 is in _mtx_lock_sleep
(/usr/src/sys/kern/kern_mutex.c:548).
543 * If the current owner of the lock is executing on
another
544 * CPU, spin instead of blocking.
545 */
546 owner = (struct thread *)(v MTX_FLAGMASK);
547 #ifdef ADAPTIVE_GIANT
548 if (TD_IS_RUNNING(owner)) {
549 #else
550 if (m != Giant TD_IS_RUNNING(owner)) {
551 #endif
552 turnstile_release(m-mtx_object);
(kgdb) backtrace
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x803f9067 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#3 0x803f9701 in panic (fmt=0xff003dbb6260 ???=) at
/usr/src/sys/kern/kern_shutdown.c:565
#4 0x8061a1ef in trap_fatal (frame=0xff003dbb6260,
eva=18446742975233640112) at /usr/src/sys/amd64/amd64/trap.c:660
#5 0x8061a716 in trap (frame=
{tf_rdi = 108, tf_rsi = -1098475937184, tf_rdx = 6, tf_rcx =
3221225730, tf_r8 = -1521574640, tf_r9 = -1098687417816, tf_rax = 1, tf_rbx =
-1099181396776, tf_rbp = 4, tf_r10 = -2138022504, tf_r11 = 0, tf_r12 =
-1098475937184, tf_r13 = 4, tf_r14 = 1, tf_r15 = 20, tf_trapno = 12, tf_addr =
396, tf_flags = -1099181396776, tf_err = 0, tf_rip = -2143360297, tf_cs = 8,
tf_rflags = 65538, tf_rsp = -1521575056, tf_ss = 16}) at
/usr/src/sys/amd64/amd64/trap.c:238
#6 0x806059ab in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:168
#7 0x803eead7 in _mtx_lock_sleep (m=0xff0013aeecd8,
tid=18446742975233614432, opts=6, file=0xc102 Address 0xc102 out of
bounds,
Re: single user mode buildwerld failures
i can't log on, but i can run in single user mode. does that qualify as a running system should i start over from step 1 and do it all in single user mode? maybe i better not try until hearing from somebody. If you have a running system, read Appendix A.5 Using CVSup [1] of the handbook, which details how to update your sources and ports to the current version. If you don't have a running system, rebuild world + kernel and hope that restores enough functionality so you can update the sources and go again. This is all described in section 22.4 Rebuilding world [2] of the handbook, but I will summarise it for you. // change to root $ su - // remove /usr/obj to speed up the build # cd /usr/obj chflags -R noschg * rm -rf * // Build a new world # cd /usr/src # make -j4 buildworld // build a new kernel (do not put any job options for this build) # make buildkernel // install the new kernel # make installkernel // reboot to single user mode (boot -s from the loader prompt) # shutdown -r now // After reboot // check + mount all filesystems # fsck -p # mount -u / # mount -a -t ufs # swapon -a // prepare /etc for the world install # mergemaster -p // install the new world # cd /usr/src ; make installworld // run mergemaster again # mergemaster // reboot to an updated system # shutdown -r now All these instructions are in the handbook. Cheers Tom [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html [2] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: single user mode buildwerld failures
i am still trying to follow the below instructions. haven't done so yet, going away for the weekend. // change to root $ su - // remove /usr/obj to speed up the build # cd /usr/obj chflags -R noschg * rm -rf * didn't do this.. but i guess that shouldn't matter. // Build a new world # cd /usr/src # make -j4 buildworld // build a new kernel (do not put any job options for this build) didn't use -j4 but otherwise i believe we did this. # make buildkernel // install the new kernel gheist seemed to be aware of this and had an opinion about not needing it. # make installkernel // reboot to single user mode (boot -s from the loader prompt) # shutdown -r now did this. // After reboot // check + mount all filesystems # fsck -p did this # mount -u / # mount -a -t ufs did merely mount -a # swapon -a // prepare /etc for the world install didn't do this. # mergemaster -p // install the new world this step is where all hell broke loose. i got this strange question that i didn't know how to respond to. my prompt changed. it felt like things went seriously wrong here. # cd /usr/src ; make installworld // run mergemaster again # mergemaster // reboot to an updated system # shutdown -r now All these instructions are in the handbook. Cheers Tom [1] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html [2] http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em0 watchdog timeout with nfs
Jack Vogel wrote: On 4/5/07, Jasper Berlijn [EMAIL PROTECTED] wrote: Hi, At this moment I'm running FreeBSD 4.11 without any problems. A couple of times I've tried to upgrade to 6.x but without any luck because of the watchdog timeout errors on em0 when using nfs. Mar 30 11:30:48 large kernel: em0: watchdog timeout -- resetting Mar 30 11:30:48 large kernel: em0: link state changed to DOWN Mar 30 11:30:51 large kernel: em0: link state changed to UP Mar 30 11:31:01 large kernel: em0: watchdog timeout -- resetting Mar 30 11:31:01 large kernel: em0: link state changed to DOWN Mar 30 11:31:03 large kernel: em0: link state changed to UP Mar 30 11:31:20 large kernel: em0: watchdog timeout -- resetting Mar 30 11:31:20 large kernel: em0: link state changed to DOWN Mar 30 11:31:23 large kernel: em0: link state changed to UP [EMAIL PROTECTED]:14:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82540EM Gigabit Ethernet Controller' class= network subclass = ethernet When I try to copy a large file (1gb) then after a couple of mb's (100mb) the wachtdog timeout will occur. The system is most of the time idle. Using debug.mpsafenet=0 in /boot/loader.conf doesn't make any difference. Any ideas? The driver in 6.2 RELEASE fixed all known problems with watchdogs, other than REAL issues with the network/hardware. Have you tried installing that? Running RELENG_6 (FreeBSD 6.2-STABLE (GENERIC) #0: Wed Mar 28 14:32:07 CEST 2007). The network is running at (1000baseTX full-duplex) This system is dual boot so it's easy to switch from 4.11 (RELENG_4) and RELENG_6. The system is running without any problem on 4.11. - Jasper ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Stack panic with em driver unload
Our test group uses a script that does 100 iterations of a module load, then bring up all interfaces, and then unload driver. Depending on the system in anything from just a few iterations to 20 or more, the system will panic. Its doing an em_detach() which calls ether_ifdetach() which goes to if_detach, in_delmulti_ifp, in_delmulti_locked, and finally if_delmulti(). The panic is always happening on a cmpxchgq instruction so I assume its the LOCK macro, whats odd is that its not always the same reason, sometimes one register is 0 so its a page fault trap, but on other iterations its a general protection fault because the register is some big invalid number :) I am hardpressed to see this as a driver problem, but I'm willing to be proven wrong, does someone who knows the stack code better than me have any insights or ideas? It also appears system dependent, I have a couple machines I've tried to reproduce in on and have been unable. I also am told it happens on both amd64 and i386, but it seems easier to reproduce on the former. Lastly, from evidence so far I think this doesnt happen on CURRENT, but the test group hasnt checked that only I have and I dont have as much hardware :) Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
Date: Thu, 5 Apr 2007 12:57:09 +0200 From: Michael Schuh [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi, first i understand your need's right! More Text on screen at boot time, but i have never get this working at boot time, but directly after boot. In my case my Kernels would be compiles with: options SC_PIXEL_MODE and in /boot/loader.conf vesa_load=YES and in /etc/rc.conf something like this: keymap=german.iso font8x16=iso15-8x16 font8x14=iso15-8x14 font8x8=iso15-8x8 allscreens_flag=MODE_280 In my case with german keyboard, change these things to your needs. The allscreens_flag you could get as mentoided in other answers with vidcontrol -i mode, i remember that someone has tell you to use MODE_279, but i doesn't know if this is the best case for all cards. For a single test you can set the mode from one terminal (like ttyv0) after logging in with vidcontrol MODE_280 or that likes to your modes for your Graphiccard. If anyone else knows how we can set the vid-mode at boot-time so that the bootmessages are every time in such a mode tell me please how it works. In the Kernel NOTEs i have only found a line like options VGA_WIGTH90, but thi is not my desired resolution. I used to do this, but I discovered that my scrollback buffer lost th 24 lines in the screen when the mode changes and I couldn't live with that. It would be nice to have the display at boot time, but, if I did not lose data, I would be happy to have it from when it starts. In any case, I figure that people who want X, will go with X. Some folks still like a plain old command-line console. I use X, but I don't start with xdm, kdm, or any other. I still like to see what is happening and enter 'startx' when I am good and ready. Sometimes I am not ready for the entire session. I don't always want all of X sitting between me and my CLI. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgp9NjEJHB9IE.pgp Description: PGP signature
Re: Changing Console Resolution - Vidcontrol
Hi Kevin, hi @list, ok losing data in output is not really nice, in my experiences i don't lose lines, they get not displayed, if i use scroll-lock and pg-up, i can see the lines they was on the screen before i change the mode. If you need more lines in buffer (esp. to supress losing lines) you can change the default (200 lines) in your kernels. take a look at /usr/src/sys/conf/NOTES and /usr/src/i386/conf/NOTES, search SC*BUFFER but keep in mind this can make a slideshow like teleporting on your console :-D (remembers me to ego-shooters and jump'n'run games) (only to be complete..) Yes i agree with they peoples that mentoid to using X and/or ssh/xterms, but i could understand the needs for getting more data and less confusion on starting up the servers. Sometimes, proably in testing, we sitting directly on the console(sometimes up on the box :-D) and we would see whats going on on boot time, so we can interrupt something more quickly. And yes, i stay very close to those who say X or graphical UI has nothing to search on a server, it uses some ressources they are assigned to services. cheers michael 2007/4/6, Kevin Oberman [EMAIL PROTECTED]: Date: Thu, 5 Apr 2007 12:57:09 +0200 From: Michael Schuh [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Hi, first i understand your need's right! More Text on screen at boot time, but i have never get this working at boot time, but directly after boot. In my case my Kernels would be compiles with: options SC_PIXEL_MODE and in /boot/loader.conf vesa_load=YES and in /etc/rc.conf something like this: keymap=german.iso font8x16=iso15-8x16 font8x14=iso15-8x14 font8x8=iso15-8x8 allscreens_flag=MODE_280 In my case with german keyboard, change these things to your needs. The allscreens_flag you could get as mentoided in other answers with vidcontrol -i mode, i remember that someone has tell you to use MODE_279, but i doesn't know if this is the best case for all cards. For a single test you can set the mode from one terminal (like ttyv0) after logging in with vidcontrol MODE_280 or that likes to your modes for your Graphiccard. If anyone else knows how we can set the vid-mode at boot-time so that the bootmessages are every time in such a mode tell me please how it works. In the Kernel NOTEs i have only found a line like options VGA_WIGTH90, but thi is not my desired resolution. I used to do this, but I discovered that my scrollback buffer lost th 24 lines in the screen when the mode changes and I couldn't live with that. It would be nice to have the display at boot time, but, if I did not lose data, I would be happy to have it from when it starts. In any case, I figure that people who want X, will go with X. Some folks still like a plain old command-line console. I use X, but I don't start with xdm, kdm, or any other. I still like to see what is happening and enter 'startx' when I am good and ready. Sometimes I am not ready for the entire session. I don't always want all of X sitting between me and my CLI. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -- === michael-schuh.net === Michael Schuh Preußenstr. 13 66111 Saarbrücken phone: 0681/8319664 mobil: 0177/9738644 @: [EMAIL PROTECTED] === Ust-ID: DE251072318 === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Changing Console Resolution - Vidcontrol
Date: Fri, 6 Apr 2007 00:31:45 +0200 From: Michael Schuh [EMAIL PROTECTED] Hi Kevin, hi @list, ok losing data in output is not really nice, in my experiences i don't lose lines, they get not displayed, if i use scroll-lock and pg-up, i can see the lines they was on the screen before i change the mode. Are you sure? On my T43, I lose exactly 23 lines at the point my screen switches from it's default mode. Note that I need to use VESA and SC_PIXEL_MODE on this system. That may relate to the problem. If you need more lines in buffer (esp. to supress losing lines) you can change the default (200 lines) in your kernels. take a look at /usr/src/sys/conf/NOTES and /usr/src/i386/conf/NOTES, search SC*BUFFER but keep in mind this can make a slideshow like teleporting on your console :-D (remembers me to ego-shooters and jump'n'run games) I always run a 2000 line scrollback buffer. 200 won't make it to the start of my boot. And, it's SC_HISTORY_SIZE. I'm unclear as to what you refer to as 'slideshow like teleporting', though. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgprMuq6pnNa5.pgp Description: PGP signature
Re: Changing Console Resolution - Vidcontrol
Hi Kevin, yes you are right my systems also loses lines, i believe that the mechanics in vidcontrol or in the kernels syscons device are the sources of this behaviour ...because through the init ( blanks screen and set mode ).. About the buffer at this time I am not really sure, but in the kernel's NOTES files it is setted per default to 200. I think you are right with the scrollback buffer that was the thing that i mean. you could have a slideshow or teleporting effect on some slow graphic cards, or on cards that not fully supports vesa while you scrolling through the screens, because if you use the vesa driver the output could be slower while having more overhead.. ...read also the postings in the stable-list ( I think from oliver fromme).. hmmm, if this behavior (losing lines) could not turned out by options or configuring the mode directly after loading the vesa module, I think it is a bug and we should enter it to the GNATS bugtracker but first we call help in the list :-) Could anyone, that is deeper in the woods, shed us some light on this behavior and eventually a possible solution? cheers michael -- === michael-schuh.net === Michael Schuh Preußenstr. 13 66111 Saarbrücken phone: 0681/8319664 mobil: 0177/9738644 @: [EMAIL PROTECTED] === Ust-ID: DE251072318 === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No buffer space available
On 05/04/07, Marc G. Fournier [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Thursday, April 05, 2007 11:06:30 + Thiago Esteves de Oliveira [EMAIL PROTECTED] wrote: Marc, My machine is working with the kernel that comes with 6.1-STABLE (I archived this good kernel before upgrade the OS to 6.2). No, I'm not using geom. Can you send your dmesg.boot and sysctl -a kern output? pid 8 (sendmail), uid 25 inumber 8577 on /var: filesystem full pid 84023 (sendmail), uid 25 inumber 8587 on /var: filesystem full pid 81719 (sendmail), uid 25 inumber 8591 on /var: filesystem full pid 85247 (sendmail), uid 25 inumber 8593 on /var: filesystem full pid 86881 (dd), uid 2 inumber 8596 on /var: filesystem full pid 90114 (dd), uid 2 inumber 8580 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 92861 (dd), uid 2 inumber 8365 on /var: filesystem full pid 96933 (dd), uid 2 inumber 8439 on /var: filesystem full pid 2289 (dd), uid 2 inumber 8480 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 4664 (sendmail), uid 25 inumber 8572 on /var: filesystem full pid 4965 (dd), uid 2 inumber 8581 on /var: filesystem full pid 5228 (sendmail), uid 25 inumber 8588 on /var: filesystem full pid 5970 (sendmail), uid 25 inumber 8592 on /var: filesystem full pid 8960 (dd), uid 2 inumber 8595 on /var: filesystem full pid 11981 (dd), uid 2 inumber 8565 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 14065 (sendmail), uid 25 inumber 8597 on /var: filesystem full pid 15495 (dd), uid 2 inumber 8600 on /var: filesystem full pid 15532 (kiplingOuija.cgi), uid 80: exited on signal 11 pid 15909 (sendmail), uid 25 inumber 8601 on /var: filesystem full pid 18424 (dd), uid 2 inumber 8510 on /var: filesystem full pid 21371 (dd), uid 2 inumber 8559 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 23625 (sendmail), uid 25 inumber 8572 on /var: filesystem full pid 24260 (sendmail), uid 25 inumber 8588 on /var: filesystem full pid 25003 (sendmail), uid 25 inumber 8592 on /var: filesystem full pid 27135 (dd), uid 2 inumber 8578 on /var: filesystem full pid 29086 (sendmail), uid 25 inumber 8596 on /var: filesystem full pid 30176 (dd), uid 2 inumber 8597 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 33170 (dd), uid 2 inumber 8581 on /var: filesystem full pid 35631 (dd), uid 2 inumber 8365 on /var: filesystem full pid 39216 (dd), uid 2 inumber 8439 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 41773 (dd), uid 2 inumber 8480 on /var: filesystem full pid 42005 (sendmail), uid 25 inumber 8572 on /var: filesystem full pid 44505 (dd), uid 2 inumber 8510 on /var: filesystem full pid 45410 (sendmail), uid 25 inumber 8580 on /var: filesystem full pid 47630 (dd), uid 2 inumber 8582 on /var: filesystem full fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled pid 49712 (sendmail), uid 25 inumber 8588 on /var: filesystem full pid 51003 (dd), uid 2 inumber 8593 on /var: filesystem full pid 51467 (sendmail), uid 25 inumber 8594 on /var: filesystem full pid 51804 (kiplingOuija.cgi), uid 80: exited on signal 11 pid 53577 (dd), uid 2 inumber 8559 on /var: filesystem full pid 54476 (sendmail), uid 25 inumber 8579 on /var: filesystem full pid 55549 (sendmail), uid 25 inumber 8601 on /var: filesystem full pid 56090 (bigOuija.cgi), uid 80: exited on signal 11 pid 57137 (dd), uid 2 inumber 8604 on /var: filesystem full pid 58015 (kiplingOuija.cgi), uid 80: exited on signal 11 fxp0: promiscuous mode disabled fxp0: promiscuous mode enabled fxp0: promiscuous mode disabled GEOM_MIRROR: Device vm: provider mirror/vm destroyed. GEOM_MIRROR: Device vm destroyed. Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...4 4 4 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 done All buffers synced. /vm: unmount pending error: blocks -64 files 0 GEOM_MIRROR: Device md2: provider mirror/md2 destroyed. GEOM_MIRROR: Device md2 destroyed. GEOM_STRIPE: Disk mirror/md2 removed from md0. GEOM_STRIPE: Device md0 removed. GEOM_MIRROR: Device md1: provider mirror/md1 destroyed. GEOM_MIRROR: Device md1 destroyed. GEOM_STRIPE: Disk mirror/md1 removed from md0. GEOM_STRIPE: Device md0 destroyed. Uptime: 3d8h23m45s Rebooting... cpu_reset: Stopping other CPUs 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-STABLE #5: Tue Mar 13 02:29:37 ADT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/kernel Timecounter
