Re: FreeBSD 9.0 amd64 RC1 and KDE4
You could try something like: script startx Then exit X when it's done, and the script command should've put the output into a text file for you. adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0 amd64 RC1 and KDE4
On Wed, Oct 26, 2011 at 7:47 PM, Arnaud Lacombe wrote: > Hi, > > On Wed, Oct 26, 2011 at 7:09 PM, Mehmet Erol Sanliturk > wrote: > > The KDE4 in FreeBSD 9.0 RC1 amd64 is generating enormous amount of error > > messages during usage ( not visible on screen , but seen after > Ctrl-Alt-F1 > > discontinuation of X ) . This is making it extremely slow which may be > > considered to be practically unusable . Actually parts are working > generally > > but every step is waiting so much that such a usage is not practically > > applicable . > > > What are the message(s) ? > > Thanks, > - Arnaud > > > The KDE4 in FreeBSD 9.0 RC1 i386 is working satisfactorily , but for > memory > > requirements , it is not an alternative . > > > > There are important usability differences between both architectures with > > respect to KDE4 execution . > > > > > > One alternative is mentioned as PC-BSD , but installation of PC-BSD is > NOT > > possible : > > > > In PC-BSD 8.2 amd64 Release and following snapshot(s) , within 18 ( > eighteen > > ) hours , only a small percent ( less than % 10 ) could be installed . > > Now , in PC-BSD 9.0 RC1 amd64 , I am still waiting : In 4 ( four ) hours > it > > could come to "Installing Meta Package : base-system" . > > Such an installation structure is really unusable . I will discontinue it > > because it seems that complete install will require many days with that > > speed . > > > > I am continuously installing many other distributions which mostly they > are > > consuming time around thirty minutes ( except upgrade during installation > , > > if it is selected ) . > > > > Thirty minutes may be considered an acceptable duration for installation > , > > let's say , time less than one hour as endurable . > > It should not be forgotten that , the task is copy of approximately 4 > Giga > > Bytes to hard disk from a DVD-Rom with an additional decompressing of > files > > . > > > > Therefore , for the KDE4 users in the amd64 platform , there is a big > > problem . > > > > This was also the case for 8.2 amd64 Release . > > > > > > > > Thank you very much . > > > > > > Mehmet Erol Sanliturk > Please see my reply to Alberto Villa . ( I am installing onto a single hard disk , I am NOT using any virtual machine . I consider using virtual machine in final testing an important error because at the end the distribution will be installed onto a bare metal . ) On that hard disk , I was trying to install PC-BSD 9.0 amd64 RC1 , to check its KDE4 usage , but due to its very long install time , I have discontinued it and I have Installed Scientific Linux . It is using KDE4 and it is working very well . Therefore , I will not be able to supply any error message at present . My opinion is that , the error messages are not directly related to my computer , but inconsistencies between compiled parts . For example , one message was about : kcheckrunning is not found . This was in /usr/local/kde4/bin directory . By thinking PATH is not properly defined , I have included /usr/local/kde4/bin into PATH , but that did not solve any problem . I have checked the 9.0 i386 RC1 PATH . It does not contain /usr/local/kde4/bin . I have studied /usr/local/kde4/bin/startkde script ( without much understanding ) of 9.0 amd64 RC1 . It seems that , it is defining path itself . I do not know whether its definition is correct or not . Perhaps the problem is in those definitions . Additionally there was "...?... crashed" messages . I do not know . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0 amd64 RC1 and KDE4
On Wed, Oct 26, 2011 at 7:33 PM, Alberto Villa wrote: > On Thursday 27 October 2011 01:09:25 Mehmet Erol Sanliturk wrote: > > The KDE4 in FreeBSD 9.0 RC1 amd64 is generating enormous amount of > error > > messages during usage ( not visible on screen , but seen after Ctrl- > Alt-F1 > > discontinuation of X ) . This is making it extremely slow which may be > > considered to be practically unusable . Actually parts are working > > generally but every step is waiting so much that such a usage is not > > practically applicable . > > You didn't say anything about those error messages, though. It might > come useful. We keep trying to improve the situation thanks to reports > from our users. > > > Therefore , for the KDE4 users in the amd64 platform , there is a big > > problem . > > > > This was also the case for 8.2 amd64 Release . > > Actually, you're the first one to report such a problem. If this "was also > the case for 8.2" you could have said it earlier. Any chance to get some > help from you to investigate the issue? > -- > Alberto Villa, FreeBSD committer > http://people.FreeBSD.org/~avilla > > Man who arrives at party two hours late > will find he has been beaten to the punch. > In a message previously I mentioned the KDE4 problem for 8.2 amd64 Release , but that message even did not receive a single reply . Always I may help with pleasure , but I do not know how . I think the problem is not related to hardware because i386 KDE4 is working very well . On the same computer , there are four hard disks , and each disk has a different operating system , mostly 64 bit ones . All of them using KDE4 and working very well . If you consider useful , my ideas are following : During start-up of KDE4 , screen is painted with its wall paper only . Since X is already running , it is possible to open a window and display messages on it with possible saving to a text file . This file may be transmitted to experts for possible studies . At present , monitors are cheap . I want to install multiple monitors on the same computer to watch serial console output on a regular ( VGA ) monitor ( because in market , there is NO any serial console on sale in computer shops ( I am in Turkey )) . Really , I do not know how to implement a regular ( VGA ) computer instead of a serial console . A very good application in FreeBSD may be to allow such a multiple monitor definition during install and use them for virtual terminals simultaneously . Using a second computer for serial console is not very practical due to software and hardware problems . If you know my actual problem , you may understand me better . I am writing a multimedia information management system as continuation of my PhD thesis feasibility demonstration program . Due to health problems it is progressing very slowly . My primary aim is to base it on a free , permissive , open source operating system . My program , with a freely usable version , will be closed source ( for sale , if I can do ) . I need a permissive ( BSD like licensed ) operating system , because a data base without operating system support can not be secure in itself . Unfortunately , I am using Pascal only , Fortran for scientific programming and very rarely C , ( with a knowledge of other many programming languages ) . I want to start on working internal structure of an operating system . Linux is NOT usable due to GPL . Minix ( does not have a capable Pascal ) , Haiku , are not sufficiently mature . NetBSD , OpenBSD , DragonFlyBSD are not better than FreeBSD . OpenSolaris died , OpenIndiana is using copyright dependent parts . The most viable selection is FreeBSD for 64 bits ... In such an environment , usability of multiple terminals ( monitors ) simultaneously as distinct display areas with output direction possibility via parameter files would be very useful . Assume values are written into distinct files , where files are monitors . Not only for my own benefits , also for contribution to humanity ( My main hobby was to write mathematical analysis programs to support researches , with very hard work : Conclusion : My wife had divorced me with a complaint that I am studying very much , occupying home with computers , etc. ) , I always wish to make contributions to FreeBSD because of its very good license ( even commercial companies may use it freely which is a very good decision for me ) and its high quality . To test the KDE4 in FreeBSD 9.0 amd64 RC1 , you can do the following : Install X . Install KDE4 . Login to console . Without an .xinitrc file , and unmodified /etc/ttys file , execute startx . ( Do not start KDE4 directly . ) In right xterm window of X , execute /usr/local/kde4/bin/startkde ( /usr/local/kde4/bin is not in path definition ) . In that terminal , you will see a lot of messages . After display of messages , a form will appear to display KDE4 . Then , I do not know , but , even this will supply much information about what is going problematic .
Re: FreeBSD 9.0 amd64 RC1 and KDE4
On Thursday 27 October 2011 01:09:25 Mehmet Erol Sanliturk wrote: > The KDE4 in FreeBSD 9.0 RC1 amd64 is generating enormous amount of error > messages during usage ( not visible on screen , but seen after Ctrl- Alt-F1 > discontinuation of X ) . This is making it extremely slow which may be > considered to be practically unusable . Actually parts are working > generally but every step is waiting so much that such a usage is not > practically applicable . You didn't say anything about those error messages, though. It might come useful. We keep trying to improve the situation thanks to reports from our users. > Therefore , for the KDE4 users in the amd64 platform , there is a big > problem . > > This was also the case for 8.2 amd64 Release . Actually, you're the first one to report such a problem. If this "was also the case for 8.2" you could have said it earlier. Any chance to get some help from you to investigate the issue? -- Alberto Villa, FreeBSD committer http://people.FreeBSD.org/~avilla Man who arrives at party two hours late will find he has been beaten to the punch. signature.asc Description: This is a digitally signed message part.
Should process in STOP state be swapped out?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I've noticed that if I kill -STOP a process, the in-core size does not change even when there is memory pressure (what I'm expecting is that if there is memory pressure, the process's in-core part gets swapped out from time to time). Is this behavior intentional? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iQEcBAEBCAAGBQJOqJ/WAAoJEATO+BI/yjfBRSIIAMeAhK/IeHHiPQUDQ6mBpilT IyA5AjnI8Gcx4XubgR7vD5Wh29X/fTakj0GIIRDX9b6ooVsr0WjCeg+xnl4LDTn1 oxw6ba42jZq1PVbgUoTS5X8n8XnfDIocCDLh2yVxaaOYMFrpS6gqYTkhMYU3GwwM uxoUxRDRiLbJ5KTTYOsBj32ZB/JF7HoUmZtWZcfUX+6oIXnM777DVc52TpCH7six prDMcX5PRmWyAIzjmuxuGrc0KrLLH/QemYW11tlFM/TRLbtCtq0oIynB1PI6aIg7 Z1K0RAgOtvAroUAm5FchFYTFsPm01GhWOZe57gGKgoF4TlnzkM2Es0Vo27w9wP8= =saI5 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0 amd64 RC1 and KDE4
Hi, On Wed, Oct 26, 2011 at 7:09 PM, Mehmet Erol Sanliturk wrote: > The KDE4 in FreeBSD 9.0 RC1 amd64 is generating enormous amount of error > messages during usage ( not visible on screen , but seen after Ctrl-Alt-F1 > discontinuation of X ) . This is making it extremely slow which may be > considered to be practically unusable . Actually parts are working generally > but every step is waiting so much that such a usage is not practically > applicable . > What are the message(s) ? Thanks, - Arnaud > The KDE4 in FreeBSD 9.0 RC1 i386 is working satisfactorily , but for memory > requirements , it is not an alternative . > > There are important usability differences between both architectures with > respect to KDE4 execution . > > > One alternative is mentioned as PC-BSD , but installation of PC-BSD is NOT > possible : > > In PC-BSD 8.2 amd64 Release and following snapshot(s) , within 18 ( eighteen > ) hours , only a small percent ( less than % 10 ) could be installed . > Now , in PC-BSD 9.0 RC1 amd64 , I am still waiting : In 4 ( four ) hours it > could come to "Installing Meta Package : base-system" . > Such an installation structure is really unusable . I will discontinue it > because it seems that complete install will require many days with that > speed . > > I am continuously installing many other distributions which mostly they are > consuming time around thirty minutes ( except upgrade during installation , > if it is selected ) . > > Thirty minutes may be considered an acceptable duration for installation , > let's say , time less than one hour as endurable . > It should not be forgotten that , the task is copy of approximately 4 Giga > Bytes to hard disk from a DVD-Rom with an additional decompressing of files > . > > Therefore , for the KDE4 users in the amd64 platform , there is a big > problem . > > This was also the case for 8.2 amd64 Release . > > > > Thank you very much . > > > Mehmet Erol Sanliturk > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 9.0 amd64 RC1 and KDE4
The KDE4 in FreeBSD 9.0 RC1 amd64 is generating enormous amount of error messages during usage ( not visible on screen , but seen after Ctrl-Alt-F1 discontinuation of X ) . This is making it extremely slow which may be considered to be practically unusable . Actually parts are working generally but every step is waiting so much that such a usage is not practically applicable . The KDE4 in FreeBSD 9.0 RC1 i386 is working satisfactorily , but for memory requirements , it is not an alternative . There are important usability differences between both architectures with respect to KDE4 execution . One alternative is mentioned as PC-BSD , but installation of PC-BSD is NOT possible : In PC-BSD 8.2 amd64 Release and following snapshot(s) , within 18 ( eighteen ) hours , only a small percent ( less than % 10 ) could be installed . Now , in PC-BSD 9.0 RC1 amd64 , I am still waiting : In 4 ( four ) hours it could come to "Installing Meta Package : base-system" . Such an installation structure is really unusable . I will discontinue it because it seems that complete install will require many days with that speed . I am continuously installing many other distributions which mostly they are consuming time around thirty minutes ( except upgrade during installation , if it is selected ) . Thirty minutes may be considered an acceptable duration for installation , let's say , time less than one hour as endurable . It should not be forgotten that , the task is copy of approximately 4 Giga Bytes to hard disk from a DVD-Rom with an additional decompressing of files . Therefore , for the KDE4 users in the amd64 platform , there is a big problem . This was also the case for 8.2 amd64 Release . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can audio CDs be played with ATA_CAM ?
On Wed, Oct 26, 2011 at 9:57 AM, Claude Buisson wrote: > > Doing my home work step by step: > > I found only 1 place in VLC where the first message: > > [0x2caf2a3c] cdda access error: Could not set block size > > is emitted, after an: > > ioctl( p_vcddev->i_device_handle, CDRIOCSETBLOCKSIZE, &i_size ) > > CDRIOCSETBLOCKSIZE is defined in sys/cdrio.h, and in the kernel used in: > > sys/dev/ata/atapi-cd.c > > which is a brought into the kernel by: > > device atapicd > > So the natural question is: > > Is this ioctl supported with ATA_CAM (and atapicam) ? > > If not, what is to be used instead ? Claude, Thanks for digging into this a bit. I just added some code to make it easier for applications to detect at runtime if ATA_CAM has been configured in the kernel: http://lists.freebsd.org/pipermail/svn-src-stable-9/2011-October/000114.html I am not 100% sure how the CD driver works with ATA_CAM. I think you might need to look at: src/sys/cam/scsi/scsi_cd.c and also read the cd(4) man page. We may need to extend scsi_cd.c, but I'm not sure. -- Craig Rodrigues rodr...@crodrigues.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
usbus seen as network devices
I've noticed that with 9.0-RC1, usbus[0-9] are seen as network interfaces. I figured this is need for usbdump to work. (This isuue has been raised before [1], but no helpful replies were given). I find this behavior rather annoying: 1) usbus0 is the default interface (in 8.2, my primary network interface was default) # tcpdump tcpdump: WARNING: usbus0: That device doesn't support promiscuous mode (BIOCPROMISC: Operation not supported) tcpdump: WARNING: usbus0: no IPv4 address assigned tcpdump: packet printing is not supported for link type USB: use -w 2) Various tools (netstat, tcpdump, wireshark, my network monotoring dockapp) now list 8 additional interfaces: # netstat -i NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll usbus 00 0 00 0 0 usbus 00 0 00 0 0 ... 3) I can do rather silly things, that at best will do nothing: # ifconfig usbus0 10.0.0.1 # usbdump -i lo0 Some applications seem to check the link type, so that unsupported interfaces are not shown. But the behavior isn't even consistent in the base system: - ifconfig -a doesn't show usbus interfaces, but lets you happily configure them - tcpdump -D shows the interfaces, but bails out if you actually start capturing - netstat shows them - systat -ifstat only lists real interfaces Do all these applications need to be patched, or can this be fixed in a single place (in the kernel)? Is there a kernel option/sysctl/etc. to disable this behavior? I'm most likely not going to need usbdump in the foreseeable future. [1] http://lists.freebsd.org/pipermail/freebsd-stable/2011- September/063941.html -- Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problems with "ada0: Previously was known as ad6" functionality
On Tue, Oct 25, 2011 at 05:01:31PM +0200, Jason Edwards wrote: > On Tue, Oct 25, 2011 at 4:35 PM, Nikolay Denev wrote: > > I was struck with this problem too yesterday. > > I was able to import the pool by specifying the directory where zpool > > should look for devices. > > Like : zpool import -d /dev/gptid > > Alternatively you can try putting kern.cam.ada.legacy_aliases=0 in your > > /boot/loader.conf > > Hello Nikolay, > > Thanks for your reply! > > The kern.cam.ada.legacy_aliases=0 indeed makes the /dev/ad6 device go > away. However, unlike I suspected, it did not solve the zpool import > problem. It still lists my pool as corrupted. If I use the zpool > import -d /dev/gpt as you suggested, the pool displays as ONLINE and I > can import it just fine. Using -d /dev works too, so I guess this > works fine as a workaround. Hmm, that's really strange. 'zpool import -d /dev ' works, but 'zpool import ' doesn't? Does, eg. 'geom disk status' work or returns an error? -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpdz8xMIULHW.pgp Description: PGP signature
Re: Fatal trap 12: page fault while in kernel mode -- Stopped at atomic_subtract_int+0x4
Fabian Keil wrote: > Fabian Keil wrote: > > > I pretty reproducible get the following (handtranscribed) panic > > when sending an zfs snapshot to geli provider based on an USB > > stick that disappears (due to a bug, or because it's unplugged): > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0: apic id = 00 > > fault virtual address = 0x288 > > fault code= supervisor write data, page not present > > instruction pointer = 0x20:0x808e2984 > > stack pointer = 0x28:0xff800023fba0 > > frame pointer = 0x28:0xff800023fbb0 > > code segment = base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 13 (g_up) > > [ thread pid 13 tid 100010 ] > > Stopped atatomic_subtract_int+0x4: lock subl %esi,(%rdi) > Here's another one, again with recent HEAD. > > This time the USB stick disappeared while the pool was > being scrubbed and dumping actually worked. The stick > seems to reproducibly disappear after scrubbing it for > a while and the panic seems to be reproducible as well. > > The stack trace looks a bit different, but I'm not sure if > this is because it's a slightly different situation or because > of changes in HEAD. They are different and can be reproduced independently. I filed PRs for them: http://www.freebsd.org/cgi/query-pr.cgi?pr=162010 http://www.freebsd.org/cgi/query-pr.cgi?pr=162036 Fabian signature.asc Description: PGP signature
Re: 9.0-RC1 panic in tcp_input: negative winow.
On 10/26/11 12:54 AM, Pawel Jakub Dawidek wrote: On Mon, Oct 24, 2011 at 08:14:22AM -0400, John Baldwin wrote: On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote: On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote: On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote: My suggestion would be that if we won't be able to fix it before 9.0, we should turn this assertion off, as the system seems to be able to recover. Shipped kernels have all assertions turned off. Yes, I'm aware of that, but many people compile their production kernels with INVARIANTS/INVARIANT_SUPPORT to fail early instead of eg. corrupting data. I'd be fine in moving this under DIAGNOSTIC or changing it into a printf, so it will be visible. No, the kernel is corrupting things in other places when this is true, so if you are running with INVARIANTS, we want to know about it. Specifically, in several places in TCP we assume that rcv_adv>= rcv_nxt, and depend on being able to do 'rcv_adv - rcv_nxt'. In this case, it looks like the difference is consistently less than one frame. I suspect the other end of the connection is sending just beyond the end of the advertised window (it probably assumes it is better to send a full frame if it has that much pending data even though part of it is beyond the window edge vs sending a truncated packet that just fills the window) and that that frame is accepted ok in the header prediction case and it's ACK is delayed, but the next packet to arrive then trips over this assumption. Since 'win' is guaranteed to be non-negative and we explicitly cast 'rcv_adv - rcv_nxt' to (int) in the following line that the assert is checking for: tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); I think we already handle this case ok and perhaps the assertion can just be removed? Not sure if others feel that it warrants a comment to note that this is the case being handled. I added debug to the places where rcv_adv and rcv_nxt are modified. Here is what happens before the panic occurs: tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022361548 rcv_adv 4022360100 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022362298 rcv_adv 4022361548 diff -750 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022363746 rcv_adv 4022362298 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022364836 rcv_adv 4022363746 diff -1090 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022366284 rcv_adv 4022364836 diff -1448 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022370628 rcv_adv 4022369690 diff -938 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022379140 rcv_adv 4022377692 diff -1448 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022387792 rcv_adv 4022386344 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022388890 rcv_adv 4022387792 diff -1098 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022390338 rcv_adv 4022388890 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 diff -221 panic: tcp_input negative window: tp 0xfe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 win=0 diff -221 I can send you the full log if you want, I've plenty of messages where rcv_adv< rcv_nxt, not all of them trigger this assertion. Might be a good place to use the new sifter tool. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gmultipath: act/act, path checking?
Hi. On 26.10.2011 12:09, Dennis Koegel wrote: > are there any plans to have gmultipath support for active/active? > > Also, is there any way to check available paths periodically? As far as > I unterstand, once gmultipath kicks a certain path due to failure, it > will never come back automatically. (And it won't ever be used if it > isn't working at boot time) I haven't tested it, but if gmultipath behaves same as other GEOM classes with on-disk metadata, new paths should be connected automatically when detected. Boot time in GEOM is not different from later operation. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can audio CDs be played with ATA_CAM ?
On 10/26/2011 13:50, Daniel O'Connor wrote: On 26/10/2011, at 20:50, Claude Buisson wrote: P.S. As I can see reading GENERIC, ATA_CAM will be the default for 9.X so there is a risk of complaints from FreeBSD workstation users (who cares ?) after the release.. Does cdparanoia work for you? With cdparanoia-3.9.8_9: YES tested on 8.2 (from Sep 18) and 9.0 (from Sep 25) both with ATA_CAM Strange, I would have thought VLC would use the same sort of access method as VLC.. I don't know what it's trying so it's hard to know why it doesn't work :( Doing my home work step by step: I found only 1 place in VLC where the first message: [0x2caf2a3c] cdda access error: Could not set block size is emitted, after an: ioctl( p_vcddev->i_device_handle, CDRIOCSETBLOCKSIZE, &i_size ) CDRIOCSETBLOCKSIZE is defined in sys/cdrio.h, and in the kernel used in: sys/dev/ata/atapi-cd.c which is a brought into the kernel by: device atapicd So the natural question is: Is this ioctl supported with ATA_CAM (and atapicam) ? If not, what is to be used instead ? Claude Buisson ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panics after AHCI timeouts
In article <111926.10138.25387@localhost> you wrote: > On Wed, Oct 26, 2011 at 2:27 AM, Alexander Kabaev wrote: > > I do see timeouts on one of my Samsung ST3750330A disks and they > > definitely do not cause any panics. The weird part in my case is that > > disk then immediately reappears as online and mirror zpool can be > > rebuilt by just onlining the disk with 'zpool online ' > > command. > > > > It seems to be happening once system has accumulated some uptime. If > > rebooted, it keeps running for a week or two with no issues, but then > > timeouts start to happen more or less reliably every single 24 hours. > > Does it correlate with high disk activity, i.e. with periodic(8)? > > On my machine, I have a feeling that timeouts occur more often > at that point, than normally... and that they also occur when multiple > processes access the disk simultaneously. I have seen a panic once last week under 9 stable. I had multiple virtual boxes running different FreeBSD versions. Each virtual host was building kernels with -j4. The host became very slow and the FreeBSD 9 virtual host paniced. I have not been able to to duplicate the panic. Larry -- Larry Baird| http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: l...@gta.com | TEL 407-380-0220, FAX 407-380-6080 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0 RC1 linking problem with i386 libs on amd64
On 2011-10-26 15:32, Dominic Fandrey wrote:
I haven't tried to dig into this. Only "unusual" properties of the system
are my non-default MAKEOBJDIRPREFIX and the use of ccache.
# uname -a
FreeBSD AryaStark.norad 9.0-RC1 FreeBSD 9.0-RC1 #0: Wed Oct 26 13:46:13 CEST
2011 root@AryaStark.norad:/usr/obj/GENERIC/amd64/usr/src/sys/GENERIC amd64
# make -VCC -VCPUTYPE -VCFLAGS
/usr/local/bin/ccache clang
athlon64-sse3
-O2 -pipe -march=athlon64-sse3
How are you setting CC and/or CFLAGS, precisely? Depending on how you
do it, the settings might not be propagated correctly to the build32
stage. Also, if you force CFLAGS to have -march=athlon64-sse3, I'm not
sure if the build32 stage can even work correctly. Just specify
CPUTYPE, that should be enough.
In any case, you can try out the attached patch, which should take care
of passing CC to the build32 stage correctly.
I would really like to have this in head, and even stable/9. It makes
it possible to just set CC in make.conf, without .ifdef trickery. Works
nicely for clang, too. :)
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 224934)
+++ Makefile.inc1 (working copy)
@@ -313,7 +313,8 @@
LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \
-DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \
- -DWITHOUT_HTML -DNO_CTF -DNO_LINT DESTDIR=${LIB32TMP}
+ -DWITHOUT_HTML -DNO_CTF -DNO_LINT -ECC -ECXX -EAS -ELD \
+ DESTDIR=${LIB32TMP}
LIB32IMAKE= ${LIB32WMAKE:NINSTALL=*:NDESTDIR=*} -DNO_INCS
.endif
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panics after AHCI timeouts
On Wed, Oct 26, 2011 at 2:27 AM, Alexander Kabaev wrote: > I do see timeouts on one of my Samsung ST3750330A disks and they > definitely do not cause any panics. The weird part in my case is that > disk then immediately reappears as online and mirror zpool can be > rebuilt by just onlining the disk with 'zpool online ' > command. > > It seems to be happening once system has accumulated some uptime. If > rebooted, it keeps running for a week or two with no issues, but then > timeouts start to happen more or less reliably every single 24 hours. Does it correlate with high disk activity, i.e. with periodic(8)? On my machine, I have a feeling that timeouts occur more often at that point, than normally... and that they also occur when multiple processes access the disk simultaneously. If it's only one process, the machine (usually) doesn't hang, even when that process is copying big files back and forth for a long period of time (it's a backup process). But interleave that process with another one accessing the same disk, and poof!, almost immediately ahci timeouts. occur. Very strange... Maybe a race condition of some sort after all? > -- > Alexander Kabaev Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: isp(4) WWNs / ISP2532
Cheers,
we have a "Qlogic ISP 2532 PCI FC-AL Adapter" here, on 9.0-RC1, which
seems to work fine with isp(4).
But: We had some trouble finding the WWNs -- per man page, there should
be sysctl entries like dev.isp.N.{wwnn,wwpn}, but they ain't here. dmesg
didn't show them either.
Booting verbose does print them.
Is the man page outdated, or a strange behaviour because this chip
isn't explicitly supported?
This question would be better answered on freebsd-scsi.
It's a bug, and it's easy to fix, but because of the impending 9.0
release I haven't done it.
There's an ioctl you can use to do the same thing and some tools in
http://people.freebsd.org/~mjacob/isp_tools.tgz that can solve what you
need.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gmultipath: act/act, path checking?
On 10/26/2011 2:09 AM, Dennis Koegel wrote: Cheers, are there any plans to have gmultipath support for active/active? I was given patches but have lacked motivation to do it. Also, is there any way to check available paths periodically? As far as I unterstand, once gmultipath kicks a certain path due to failure, it will never come back automatically. (And it won't ever be used if it isn't working at boot time) That is something that should have been fixed. I might be confused with the changes I did for Panasas that didn't make it back here, but I certainly had a rolling test where I ran for several days periodically failing one path and then then the other. I've found some discussion about this from 2008, but nothing since... Thanks, - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
9.0 RC1 linking problem with i386 libs on amd64
I haven't tried to dig into this. Only "unusual" properties of the system are my non-default MAKEOBJDIRPREFIX and the use of ccache. # uname -a FreeBSD AryaStark.norad 9.0-RC1 FreeBSD 9.0-RC1 #0: Wed Oct 26 13:46:13 CEST 2011 root@AryaStark.norad:/usr/obj/GENERIC/amd64/usr/src/sys/GENERIC amd64 # make -VCC -VCPUTYPE -VCFLAGS /usr/local/bin/ccache clang athlon64-sse3 -O2 -pipe -march=athlon64-sse3 ... ===> lib/csu/i386-elf (obj,depend,all,install) ld -m elf_i386_fbsd -Y P,/usr/obj/GENERIC/amd64/usr/src/lib32/usr/lib32 -o gcrt1.o -r crt1_s.o gcrt1_c.o ld: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported *** Error code 1 Stop in /usr/src/lib/csu/i386-elf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-RC1 panic in tcp_input: negative winow.
On Wednesday, October 26, 2011 3:54:31 am Pawel Jakub Dawidek wrote: > On Mon, Oct 24, 2011 at 08:14:22AM -0400, John Baldwin wrote: > > On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote: > > > On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote: > > > > On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote: > > > > > My suggestion would be that if we won't be able to fix it before 9.0, > > > > > we should turn this assertion off, as the system seems to be able to > > > > > recover. > > > > > > > > Shipped kernels have all assertions turned off. > > > > > > Yes, I'm aware of that, but many people compile their production kernels > > > with INVARIANTS/INVARIANT_SUPPORT to fail early instead of eg. > > > corrupting data. I'd be fine in moving this under DIAGNOSTIC or changing > > > it into a printf, so it will be visible. > > > > No, the kernel is corrupting things in other places when this is true, so > > if you are running with INVARIANTS, we want to know about it. > > Specifically, > > in several places in TCP we assume that rcv_adv >= rcv_nxt, and depend on > > being able to do 'rcv_adv - rcv_nxt'. > > > > In this case, it looks like the difference is consistently less than one > > frame. I suspect the other end of the connection is sending just beyond > > the > > end of the advertised window (it probably assumes it is better to send a > > full > > frame if it has that much pending data even though part of it is beyond the > > window edge vs sending a truncated packet that just fills the window) and > > that > > that frame is accepted ok in the header prediction case and it's ACK is > > delayed, but the next packet to arrive then trips over this assumption. > > > > Since 'win' is guaranteed to be non-negative and we explicitly cast > > 'rcv_adv - rcv_nxt' to (int) in the following line that the assert is > > checking > > for: > > > > tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); > > > > I think we already handle this case ok and perhaps the assertion can just be > > removed? Not sure if others feel that it warrants a comment to note that > > this > > is the case being handled. > > I added debug to the places where rcv_adv and rcv_nxt are modified. Here > is what happens before the panic occurs: > > tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022361548 > rcv_adv 4022360100 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022362298 > rcv_adv 4022361548 diff -750 > tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022363746 > rcv_adv 4022362298 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022364836 > rcv_adv 4022363746 diff -1090 > tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022366284 > rcv_adv 4022364836 diff -1448 > tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022370628 > rcv_adv 4022369690 diff -938 > tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022379140 > rcv_adv 4022377692 diff -1448 > tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022387792 > rcv_adv 4022386344 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022388890 > rcv_adv 4022387792 diff -1098 > tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022390338 > rcv_adv 4022388890 diff -1448 > tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022394563 > rcv_adv 4022394342 diff -221 > panic: tcp_input negative window: tp 0xfe000dab1b70 rcv_nxt 4022394563 > rcv_adv 4022394342 win=0 diff -221 > > I can send you the full log if you want, I've plenty of messages where > rcv_adv < rcv_nxt, not all of them trigger this assertion. The assertion would be triggered when the next packet arrives (as I said above). Try modifying your debugging output to also log if the ACK is delayed. I suspect it is not delayed until the last one. (Pushing out an ACK will reset rcv_adv to be beyond rcv_nxt in tcp_output(), so in the case of an immediate ACK, rcv_nxt > rcv_adv is only a transient condition all under a single lock invocation so never visible to other consumers of the protocol control block.) If that is what you see, then that confirms what I guessed above and I will likely just remove the assertion in tcp_input() and patch the timewait code to handle this case. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can audio CDs be played with ATA_CAM ?
On 26/10/2011, at 20:50, Claude Buisson wrote: >>> P.S. As I can see reading GENERIC, ATA_CAM will be the default for 9.X so >>> there >>> is a risk of complaints from FreeBSD workstation users (who cares ?) after >>> the >>> release.. >> >> >> Does cdparanoia work for you? >> > > With cdparanoia-3.9.8_9: YES > > tested on 8.2 (from Sep 18) and 9.0 (from Sep 25) both with ATA_CAM Strange, I would have thought VLC would use the same sort of access method as VLC.. I don't know what it's trying so it's hard to know why it doesn't work :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can audio CDs be played with ATA_CAM ?
On 10/26/2011 11:22, Daniel O'Connor wrote: On 26/10/2011, at 19:03, Claude Buisson wrote: [0x2caf2a3c] cdda access error: Could not set block size [0x2caf2a3c] cdda access error: cannot read sector n incrementing each time the sector number. So I infer that vlc cannot set the correct (audio specific) sector size for the cam device. Thanks for your attention. Claude Buisson P.S. As I can see reading GENERIC, ATA_CAM will be the default for 9.X so there is a risk of complaints from FreeBSD workstation users (who cares ?) after the release.. Does cdparanoia work for you? With cdparanoia-3.9.8_9: YES tested on 8.2 (from Sep 18) and 9.0 (from Sep 25) both with ATA_CAM Claude Buisson ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can audio CDs be played with ATA_CAM ?
On 26/10/2011, at 19:03, Claude Buisson wrote: > > [0x2caf2a3c] cdda access error: Could not set block size > [0x2caf2a3c] cdda access error: cannot read sector n > > incrementing each time the sector number. > > So I infer that vlc cannot set the correct (audio specific) sector size for > the > cam device. > > Thanks for your attention. > > Claude Buisson > > P.S. As I can see reading GENERIC, ATA_CAM will be the default for 9.X so > there > is a risk of complaints from FreeBSD workstation users (who cares ?) after the > release.. Does cdparanoia work for you? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
gmultipath: act/act, path checking?
Cheers, are there any plans to have gmultipath support for active/active? Also, is there any way to check available paths periodically? As far as I unterstand, once gmultipath kicks a certain path due to failure, it will never come back automatically. (And it won't ever be used if it isn't working at boot time) I've found some discussion about this from 2008, but nothing since... Thanks, - D. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can audio CDs be played with ATA_CAM ?
On 10/26/2011 03:28, Craig Rodrigues wrote: On Tue, Oct 25, 2011 at 3:15 AM, Claude Buisson wrote: Hi, When upgrading a system to 8.2-STABLE, I switched my kernel from atapicam to ATA_CAM, and found that vlc could not play audio CDs anymore. Reverting to atapicam (and reverting from cdN to acdN of course), vlc was OK again. Hi, Would vlc have worked if, while ATA_CAM was enabled, there was a symlink so that /dev/acd0 -> cd0 ? Just to be sure, I just made the test, and the answer is: NO I have already written that vlc writes a susccession of messages [0x2caf2a3c] cdda access error: Could not set block size [0x2caf2a3c] cdda access error: cannot read sector n incrementing each time the sector number. So I infer that vlc cannot set the correct (audio specific) sector size for the cam device. Thanks for your attention. Claude Buisson P.S. As I can see reading GENERIC, ATA_CAM will be the default for 9.X so there is a risk of complaints from FreeBSD workstation users (who cares ?) after the release.. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-RC1 panic in tcp_input: negative winow.
On Mon, Oct 24, 2011 at 08:14:22AM -0400, John Baldwin wrote: > On Sunday, October 23, 2011 11:58:28 am Pawel Jakub Dawidek wrote: > > On Sun, Oct 23, 2011 at 11:44:45AM +0300, Kostik Belousov wrote: > > > On Sun, Oct 23, 2011 at 08:10:38AM +0200, Pawel Jakub Dawidek wrote: > > > > My suggestion would be that if we won't be able to fix it before 9.0, > > > > we should turn this assertion off, as the system seems to be able to > > > > recover. > > > > > > Shipped kernels have all assertions turned off. > > > > Yes, I'm aware of that, but many people compile their production kernels > > with INVARIANTS/INVARIANT_SUPPORT to fail early instead of eg. > > corrupting data. I'd be fine in moving this under DIAGNOSTIC or changing > > it into a printf, so it will be visible. > > No, the kernel is corrupting things in other places when this is true, so > if you are running with INVARIANTS, we want to know about it. Specifically, > in several places in TCP we assume that rcv_adv >= rcv_nxt, and depend on > being able to do 'rcv_adv - rcv_nxt'. > > In this case, it looks like the difference is consistently less than one > frame. I suspect the other end of the connection is sending just beyond the > end of the advertised window (it probably assumes it is better to send a full > frame if it has that much pending data even though part of it is beyond the > window edge vs sending a truncated packet that just fills the window) and that > that frame is accepted ok in the header prediction case and it's ACK is > delayed, but the next packet to arrive then trips over this assumption. > > Since 'win' is guaranteed to be non-negative and we explicitly cast > 'rcv_adv - rcv_nxt' to (int) in the following line that the assert is checking > for: > > tp->rcv_wnd = imax(win, (int)(tp->rcv_adv - tp->rcv_nxt)); > > I think we already handle this case ok and perhaps the assertion can just be > removed? Not sure if others feel that it warrants a comment to note that this > is the case being handled. I added debug to the places where rcv_adv and rcv_nxt are modified. Here is what happens before the panic occurs: tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022361548 rcv_adv 4022360100 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022362298 rcv_adv 4022361548 diff -750 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022363746 rcv_adv 4022362298 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022364836 rcv_adv 4022363746 diff -1090 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022366284 rcv_adv 4022364836 diff -1448 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022370628 rcv_adv 4022369690 diff -938 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022379140 rcv_adv 4022377692 diff -1448 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022387792 rcv_adv 4022386344 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022388890 rcv_adv 4022387792 diff -1098 tcp_do_segment:1722 negative window: tp 0xfe000dab1b70 rcv_nxt 4022390338 rcv_adv 4022388890 diff -1448 tcp_do_segment:2847 negative window: tp 0xfe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 diff -221 panic: tcp_input negative window: tp 0xfe000dab1b70 rcv_nxt 4022394563 rcv_adv 4022394342 win=0 diff -221 I can send you the full log if you want, I've plenty of messages where rcv_adv < rcv_nxt, not all of them trigger this assertion. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpjTSToeUp9v.pgp Description: PGP signature
isp(4) WWNs / ISP2532
Cheers,
we have a "Qlogic ISP 2532 PCI FC-AL Adapter" here, on 9.0-RC1, which
seems to work fine with isp(4).
But: We had some trouble finding the WWNs -- per man page, there should
be sysctl entries like dev.isp.N.{wwnn,wwpn}, but they ain't here. dmesg
didn't show them either.
Booting verbose does print them.
Is the man page outdated, or a strange behaviour because this chip
isn't explicitly supported?
Thanks,
- D.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
