Re: About the type of physaddr in struct usb_page.
On 06/02/14 03:22, Kohji Okuno wrote:
Hi HPS,
I think the type of physaddr in struct usb_page is incorrect.
We shuld use bus_addr_t for physaddr.
What do you think about this?
60 * The following structure defines physical and non kernel virtual
61 * address of a memory page having size USB_PAGE_SIZE.
62 */
63 struct usb_page {
64 #if USB_HAVE_BUSDMA
65 bus_size_t physaddr;
66 void *buffer; /* non Kernel Virtual Address */
67 #endif
68 };
Regards,
Kohji Okuno
Hi,
http://svnweb.freebsd.org/changeset/base/266969
--HPS
___
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: Change for the worse in rsu wireless driver
On 06/02/14 07:30, Thomas Mueller wrote: I sent this message, without this top part, over an hour ago, and notice wlan0 is still up. I intended but forgot to CC to freebsd-current. But I am in newcons, having not started X so far this boot session. Maybe something rotten with Xorg, or interaction between rsu and X, or rsu and Firefox. I am afraid to try again with X, don't want to mess the file system to the extent of losing data. WLAN device is Hiro H50191 USB wireless adapter, chipset RTL8191SU. I just updated FreeBSD-current, both amd64 and i386, now both rsu and Xorg are highly unstable, at least on amd64. FreeBSD amelia4 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r266948: Sun Jun 1 19:12:44 UTC 2014 root@amelia4:/usr/obj/usr/src/sys/SANDY11NC amd64 root@amelia4:~ # ls -l /usr/src/sys/dev/usb/wlan total 1164 -rw-r--r-- 1 root wheel 65759 Jun 1 16:23 if_rsu.c -rw-r--r-- 1 root wheel 19964 Jun 1 16:23 if_rsureg.h (snip) This is a change for the worse. Now I can connect with Hiro H50191; bug in re Ethernet driver persists, so I can't connect that way. I also had several crashes in Xorg, so am typing this with vi in newcons. Tom Hi, Re-compile the rsu module with USB debugging enabled: Add to: sys/modules/usb/rsu/Makefile CFLAGS+= -DUSB_DEBUG Rebuild and install. After that lookup the debug knob using "sysctl hw.usb | grep rsu" and set it to 16. Then collect some debug messages in dmesg, when problems appear. Thank you. --HPS ___ 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: diskid documentation
On 02.06.2014 01:32, Adam McDougall wrote: > Also, I believe it is only in 10.0-RELEASE and higher. Even if your > kernel supports it, /dev/diskid will not exist if no hardware is found > with supported strings (tested in a VM just now). Probably, they just disappeared like all other labels, when you got access to disk not through the label. -- WBR, Andrey V. Elsukov ___ 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"
using single gcc compiler
Hi I use freebsd-10 as desktop . Compiling the system takes ages, and rather long time is spent in compiling different gcc compiler versions for various ports, e.g. - gcc-4.7.3- required by avidemux; - gcc-4.6.4_1,1: required by opera,operaplugins, gcc, gcc4.8 - gcc 4.8.4_xxx: required by rawtherapee Is there a way to specify that I want to use gcc 4.8.4 for all compilations which do not use clang? rgds Krasznai András rendszermérnök M&S Informatikai Zrt. 1136 Budapest, Pannónia u. 17/A. Telefon: +36 1 703-2923 Mobil:+36 30 703-2923 ___ 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: using single gcc compiler
On 2014-06-02 07:05, M&S - Krasznai András wrote: Hi I use freebsd-10 as desktop . Compiling the system takes ages, and rather long time is spent in compiling different gcc compiler versions for various ports, e.g. - gcc-4.7.3- required by avidemux; - gcc-4.6.4_1,1: required by opera,operaplugins, gcc, gcc4.8 - gcc 4.8.4_xxx: required by rawtherapee Is there a way to specify that I want to use gcc 4.8.4 for all compilations which do not use clang? Some ports only work with specific versions of GCC. If you believe a specific port should be able to use GCC 4.8.4 I would recommend testing it and filing a PR so the port maintainer can confirm and update the port. ___ 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: using single gcc compiler
On 2014-06-02 08:52, Mark Felder wrote: > On 2014-06-02 07:05, M&S - Krasznai András wrote: >> Hi >> >> >> I use freebsd-10 as desktop . >> >> Compiling the system takes ages, and rather long time is spent in >> compiling different gcc compiler versions for various ports, >> e.g. >> - gcc-4.7.3- required by avidemux; >> - gcc-4.6.4_1,1: required by opera,operaplugins, gcc, gcc4.8 >> - gcc 4.8.4_xxx: required by rawtherapee >> >> >> Is there a way to specify that I want to use gcc 4.8.4 for all >> compilations which do not use clang? >> > > Some ports only work with specific versions of GCC. If you believe a > specific port should be able to use GCC 4.8.4 I would recommend testing > it and filing a PR so the port maintainer can confirm and update the port. > ___ > 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" GCC_DEFAULT_VERSION is set to 4.6 in ports/Mk/bsd.gcc.mk Unlike some other default versions, it isn't setup to be able to be overridden from make.conf As Mark mentioned, some applications have a requirement for a specific version of gcc, while others will specify a minimum version (USE_GCC=4.7+) This is why you end up needing all of those versions. You may be able to reduce some of the fragmentation by installing the highest version first, then any app that can use that will, and only those requiring a specific version will pull those in. The root issue is that some apps will just refuse to compile on newer versions of GCC -- Allan Jude ___ 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: diskid documentation
On 2014-06-01 09:41, Michael W. Lucas wrote: > Hi, > > I'm trying to track down the documentation for the /dev/diskid/blah > device nodes. Is there a man page? > > It appears that this is a current-only thing, so I'm asking here? (At > least, none of my 9.x or 10.x machines have /dev/diskid.) > > Thanks, > ==ml > > > diskid (also called disk_ident in sysctl, which is confusing) It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) I usually disable it, especially to make my 'zpool status' output prettier kern.geom.label.disk_ident.enable=0 kern.geom.label.gptid.enable=0 -- Allan Jude ___ 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: using single gcc compiler
Thanks. I will check which of my installed ports require any special gcc version, and which specify a minimal version. Then I will try to find replacement for those which require a fixed version. rgds Andras Krasznai -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Allan Jude Sent: Monday, June 02, 2014 3:22 PM To: freebsd-current@freebsd.org Subject: Re: using single gcc compiler On 2014-06-02 08:52, Mark Felder wrote: > On 2014-06-02 07:05, M&S - Krasznai András wrote: >> Hi >> >> >> I use freebsd-10 as desktop . >> >> Compiling the system takes ages, and rather long time is spent in >> compiling different gcc compiler versions for various ports, e.g. >> - gcc-4.7.3- required by avidemux; >> - gcc-4.6.4_1,1: required by opera,operaplugins, gcc, gcc4.8 >> - gcc 4.8.4_xxx: required by rawtherapee >> >> >> Is there a way to specify that I want to use gcc 4.8.4 for all >> compilations which do not use clang? >> > > Some ports only work with specific versions of GCC. If you believe a > specific port should be able to use GCC 4.8.4 I would recommend > testing it and filing a PR so the port maintainer can confirm and update the > port. > ___ > 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" GCC_DEFAULT_VERSION is set to 4.6 in ports/Mk/bsd.gcc.mk Unlike some other default versions, it isn't setup to be able to be overridden from make.conf As Mark mentioned, some applications have a requirement for a specific version of gcc, while others will specify a minimum version (USE_GCC=4.7+) This is why you end up needing all of those versions. You may be able to reduce some of the fragmentation by installing the highest version first, then any app that can use that will, and only those requiring a specific version will pull those in. The root issue is that some apps will just refuse to compile on newer versions of GCC -- Allan Jude ___ 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"
Re: diskid documentation
On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: > It also tends to sometimes hide the gpt label provider on me (not sure > in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. ___ 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: official pkg repo with WITHOUT_X11=true
According to David Chisnall on Thu, May 29, 2014 at 10:19:41AM +0100: > We can probably do a bit better by looking at the complete dependency graph > and removing any ports that have unconditional dependencies on X. For a > headless server, there's no reason to build any of the kde-* or gnome-* ports > or, indeed, X itself. I suspect that we could easily trim 2/3 of the build > time by omitting ports that have a GUI, GUI toolkits, and so on. May I disagree? The only thing you don't need on an headless server is X itself. I might want to run firefox on that server, the display taken into account in the client machine (e.g. through ssh -X). Or did I missed something? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ ___ 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"
isp(4) Qlogic ISP 2422 PCI-X on amd64 or sparc64?
I've a storage array accessed with an isp(4) device from ia64/FreeBSD box. I'm looking for a better supported alternative to ia64, e.g. amd64 or sparc64 to house this isp(4) device: isp0@pci0:192:1:0: class=0x0c0400 card=0x12d6103c chip=0x24221077 rev=0x02 hdr=0x00 vendor = 'QLogic Corp.' device = 'ISP2422-based 4Gb Fibre Channel to PCI-X HBA' class = serial bus subclass = Fibre Channel isp0: port 0xc000-0xc0ff mem 0xe004-0xe0040fff irq 71 at device 1.0 on pci192 Has anybody used this device successfully on either amd64 or sparc64 FreeBSD recently, i.e. 10-stable or HEAD? Any specific recommendation for a FreeBSD server to house this device? Thanks Anton ___ 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: official pkg repo with WITHOUT_X11=true
On 2 Jun 2014, at 16:12, Ollivier Robert wrote: > According to David Chisnall on Thu, May 29, 2014 at 10:19:41AM +0100: >> We can probably do a bit better by looking at the complete dependency graph >> and removing any ports that have unconditional dependencies on X. For a >> headless server, there's no reason to build any of the kde-* or gnome-* >> ports or, indeed, X itself. I suspect that we could easily trim 2/3 of the >> build time by omitting ports that have a GUI, GUI toolkits, and so on. > > May I disagree? The only thing you don't need on an headless server is X > itself. I might want to run firefox on that server, the display taken into > account in the client machine (e.g. through ssh -X). > > Or did I missed something? Yes. If you want to have the graphical versions of everything on the server, then there's nothing stopping you from using the default package repository. THe use case for the proposed no-X repo is installing a headless server where you won't be doing X forwarding, and so want versions of tools that are command-line-only. If you're explicitly choosing not to install the GUI for Vim, the odds are you won't want Firefox either... David ___ 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: official pkg repo with WITHOUT_X11=true
According to David Chisnall on Mon, Jun 02, 2014 at 04:27:23PM +0100: > Yes. If you want to have the graphical versions of everything on the server, > then there's nothing stopping you from using the default package repository. > THe use case for the proposed no-X repo is installing a headless server where > you won't be doing X forwarding, and so want versions of tools that are > command-line-only. If you're explicitly choosing not to install the GUI for > Vim, the odds are you won't want Firefox either... Seems logical, yes :) Thanks. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ ___ 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: diskid documentation
On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: > On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: > > It also tends to sometimes hide the gpt label provider on me (not sure > > in which cases it does this, but it is annoying) > > This happens when something (e.g. zfs) happens to open the diskid > provider instead of the gpt label. For me this ended up being a bit > more than annoying; my swap was mounted in /etc/fstab via a gpt label > so I silently lost my swap when I did an upgrade. Wait-- one type of one label can hide another? I thought a big point of labels was to remove ambiguity... ==ml -- Michael W. Lucas - mwlu...@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ ___ 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: diskid documentation
On Mon, 2 Jun 2014, Michael W. Lucas wrote: On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. Wait-- one type of one label can hide another? I thought a big point of labels was to remove ambiguity... Can't get more unambiguous than only having one label! The word to look for here is "wither". When a device label name is opened exclusively (like mounting a device), other labels for that device are supposed to "wither" and disappear from view. (My understanding of this is incomplete. Garrett Wollman sent me a very nice explanation of how this works, which I have read but not enough times yet.) ___ 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: diskid documentation
On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. I have seen this too, starting from a fresh install. The install process for stable/10 writes a /dev/gpt style label into /etc/fstab for the swap space, and that never gets used, because the /dev/diskid/ stuff appears to take precedence. I put the following into /boot/loader.conf to make the system more sane: kern.geom.label.disk_ident.enable=0 -Kurt ___ 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: diskid documentation
On 06/02/14 08:50, Kurt Lidl wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. I have seen this too, starting from a fresh install. The install process for stable/10 writes a /dev/gpt style label into /etc/fstab for the swap space, and that never gets used, because the /dev/diskid/ stuff appears to take precedence. The installer doesn't actually do this. It would be kind of nice if it did, but the label code is fantastically unreliable (for the reason you mention as well as others). So, while it does set labels on the disk, it does not use them. -Nathan I put the following into /boot/loader.conf to make the system more sane: kern.geom.label.disk_ident.enable=0 -Kurt ___ 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"
Re: diskid documentation
Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: > On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: > > On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: > > > It also tends to sometimes hide the gpt label provider on me (not sure > > > in which cases it does this, but it is annoying) > > > > This happens when something (e.g. zfs) happens to open the diskid > > provider instead of the gpt label. For me this ended up being a bit > > more than annoying; my swap was mounted in /etc/fstab via a gpt label > > so I silently lost my swap when I did an upgrade. > > Wait-- one type of one label can hide another? > > I thought a big point of labels was to remove ambiguity... Surprisingly, yes... I didn't think about this, but it's true... A disk will get exported via two different devices, diskid and normal da/ada... The tasting will go through and create all the necessary sub devices, but the problem is that we now have two different paths, and if something opens the diskid path, then the da/ada paths all disappear... This sounds like we need to fix geom to "bind" the two together so that when one opens, the other doesn't disappear... The problem is that geom views them as two separate disks when in fact they are the same... someone who knows geom well should think about how to solve this problem, as diskid isn't the first time this has happened, just most prevalent w/ ZFS and diskid. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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) Qlogic ISP 2422 PCI-X on amd64 or sparc64?
On Monday, June 02, 2014 9:08:30 am Anton Shterenlikht wrote: > I've a storage array accessed with an isp(4) device > from ia64/FreeBSD box. I'm looking for a better supported > alternative to ia64, e.g. amd64 or sparc64 to house > this isp(4) device: > > isp0@pci0:192:1:0: class=0x0c0400 card=0x12d6103c chip=0x24221077 rev=0x02 hdr=0x00 > vendor = 'QLogic Corp.' > device = 'ISP2422-based 4Gb Fibre Channel to PCI-X HBA' > class = serial bus > subclass = Fibre Channel > > isp0: port 0xc000-0xc0ff mem 0xe004-0xe0040fff irq 71 at device 1.0 on pci192 If it works fine on ia64 it will probably work at least as well under amd64. -- 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: diskid documentation
On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote: > Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: > > On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: > > > On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: > > > > It also tends to sometimes hide the gpt label provider on me (not sure > > > > in which cases it does this, but it is annoying) > > > > > > This happens when something (e.g. zfs) happens to open the diskid > > > provider instead of the gpt label. For me this ended up being a bit > > > more than annoying; my swap was mounted in /etc/fstab via a gpt label > > > so I silently lost my swap when I did an upgrade. > > > > Wait-- one type of one label can hide another? > > > > I thought a big point of labels was to remove ambiguity... > > Surprisingly, yes... I didn't think about this, but it's true... > > A disk will get exported via two different devices, diskid and normal > da/ada... The tasting will go through and create all the necessary > sub devices, but the problem is that we now have two different paths, > and if something opens the diskid path, then the da/ada paths all > disappear... > > This sounds like we need to fix geom to "bind" the two together so > that when one opens, the other doesn't disappear... The problem is > that geom views them as two separate disks when in fact they are the > same... someone who knows geom well should think about how to solve > this problem, as diskid isn't the first time this has happened, just > most prevalent w/ ZFS and diskid. The problem is that GPT labels (or GPT IDs for that matter) should not be implemented within GLABEL. This is wrong. It should be implemented as part of GPART, so that GPART would create ada0p1, gpt/label and gptid/whatever. Opening one of those should not make the others disappear then. Only opening ada0 for writting would make them disappear. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com pgp8HNxiuiLpJ.pgp Description: PGP signature
Re: diskid documentation
On 06/02/14 13:26, Pawel Jakub Dawidek wrote: On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote: Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. Wait-- one type of one label can hide another? I thought a big point of labels was to remove ambiguity... Surprisingly, yes... I didn't think about this, but it's true... A disk will get exported via two different devices, diskid and normal da/ada... The tasting will go through and create all the necessary sub devices, but the problem is that we now have two different paths, and if something opens the diskid path, then the da/ada paths all disappear... This sounds like we need to fix geom to "bind" the two together so that when one opens, the other doesn't disappear... The problem is that geom views them as two separate disks when in fact they are the same... someone who knows geom well should think about how to solve this problem, as diskid isn't the first time this has happened, just most prevalent w/ ZFS and diskid. The problem is that GPT labels (or GPT IDs for that matter) should not be implemented within GLABEL. This is wrong. It should be implemented as part of GPART, so that GPART would create ada0p1, gpt/label and gptid/whatever. Opening one of those should not make the others disappear then. Only opening ada0 for writting would make them disappear. Indeed. This would also fix some tasting races, allow programmatic retrieval of the label device from gpart, and expand label device support from GPT to all partition schemes supported by gpart (APM, for instance). -Nathan ___ 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"
NIC driver API committed
All, A new NIC driver API has been committed that allows us to make the ifnet structure an abstract type. The abstract type being 'if_t'. The miibus(4), fxp(4), em(4) and bxe(4) drivers have been converted to use the API already. Other drivers will follow in the coming weeks. The conversion is mechanical and does not change the behavior of the drivers. As such, there's no user-visible impact. If you do run into a problem after upgrading and you're using any of the converted drivers, please let me know. It is always possible that the conversion introduces a bug. To test whether the conversion introduced the problem, revert any of the following revisions depending on the driver that gives you the problem: r266974 miibus(4) r266977 fxp(4) r266978 em(4) r266979 bxe(4) If you find yourself reverting r266974, please also revert the other 3 revisions as they depend on r266974. FYI, -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
"CPU0: local APIC error 0x40"
Some machines, including ThinkPad T61, emit the following error message
early during boot:
CPU0: local APIC error 0x40
The message itself doesn't seem to be much of a problem. However,
every once in a while booting hangs just before that line. I've tracked
that down to call to AcpiHwWritePort() at
sys/contrib/dev/acpica/components/hardware/hwacpi.c:117:
switch (Mode)
{
case ACPI_SYS_MODE_ACPI:
/* BIOS should have disabled ALL fixed and GP events */
Status = AcpiHwWritePort (AcpiGbl_FADT.SmiCommand,
(UINT32) AcpiGbl_FADT.AcpiEnable, 8);
Any idea what might be going on?
___
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: diskid documentation
Pawel Jakub Dawidek wrote this message on Mon, Jun 02, 2014 at 22:26 +0200: > On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote: > > Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: > > > On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: > > > > On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude > > > > wrote: > > > > > It also tends to sometimes hide the gpt label provider on me (not sure > > > > > in which cases it does this, but it is annoying) > > > > > > > > This happens when something (e.g. zfs) happens to open the diskid > > > > provider instead of the gpt label. For me this ended up being a bit > > > > more than annoying; my swap was mounted in /etc/fstab via a gpt label > > > > so I silently lost my swap when I did an upgrade. > > > > > > Wait-- one type of one label can hide another? > > > > > > I thought a big point of labels was to remove ambiguity... > > > > Surprisingly, yes... I didn't think about this, but it's true... > > > > A disk will get exported via two different devices, diskid and normal > > da/ada... The tasting will go through and create all the necessary > > sub devices, but the problem is that we now have two different paths, > > and if something opens the diskid path, then the da/ada paths all > > disappear... > > > > This sounds like we need to fix geom to "bind" the two together so > > that when one opens, the other doesn't disappear... The problem is > > that geom views them as two separate disks when in fact they are the > > same... someone who knows geom well should think about how to solve > > this problem, as diskid isn't the first time this has happened, just > > most prevalent w/ ZFS and diskid. > > The problem is that GPT labels (or GPT IDs for that matter) should not > be implemented within GLABEL. This is wrong. It should be implemented as > part of GPART, so that GPART would create ada0p1, gpt/label and > gptid/whatever. Opening one of those should not make the others > disappear then. Only opening ada0 for writting would make them disappear. even gpart would be wrong IMO... What happens if there is another provider like GPART, but different, do they need to implement diskid creation too to prevent the same issue? Shouldn't geom be updated to say, this ident is an alias, everything you do w/ this, it's exactly the same as the other one? This would also have the advantage of possibly removing one layer in the call chain when dealing w/ IO. (or does GEOM has a pass-through flag that says, I don't do anything, just skip me?) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ 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: diskid documentation
On 2014-06-02 10:45, Ryan Stone wrote: > On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: >> It also tends to sometimes hide the gpt label provider on me (not sure >> in which cases it does this, but it is annoying) > > This happens when something (e.g. zfs) happens to open the diskid > provider instead of the gpt label. For me this ended up being a bit > more than annoying; my swap was mounted in /etc/fstab via a gpt label > so I silently lost my swap when I did an upgrade. > ___ > 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" > Exactly. It makes sense that ZFS sees the DiskID first or whatever, but why does the gpt label disappear entirely? -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: diskid documentation
On 2014-06-02 11:50, Kurt Lidl wrote: >> On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude >> wrote: >>> It also tends to sometimes hide the gpt label provider on me (not sure >>> in which cases it does this, but it is annoying) >> >> This happens when something (e.g. zfs) happens to open the diskid >> provider instead of the gpt label. For me this ended up being a bit >> more than annoying; my swap was mounted in /etc/fstab via a gpt label >> so I silently lost my swap when I did an upgrade. > > I have seen this too, starting from a fresh install. > > The install process for stable/10 writes a /dev/gpt style label > into /etc/fstab for the swap space, and that never gets used, > because the /dev/diskid/ stuff appears to take precedence. > > I put the following into /boot/loader.conf to make the system more > sane: > > kern.geom.label.disk_ident.enable=0 > > -Kurt > > ___ > 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" I have a patch for the installer that solves this issue by explicitly using /dev/adaXpY or adaXsYb etc I thought the label was a nice way to do it, but it backfired. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: diskid documentation
On 06/02/14 15:32, Allan Jude wrote: On 2014-06-02 11:50, Kurt Lidl wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. I have seen this too, starting from a fresh install. The install process for stable/10 writes a /dev/gpt style label into /etc/fstab for the swap space, and that never gets used, because the /dev/diskid/ stuff appears to take precedence. I put the following into /boot/loader.conf to make the system more sane: kern.geom.label.disk_ident.enable=0 -Kurt ___ 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" I have a patch for the installer that solves this issue by explicitly using /dev/adaXpY or adaXsYb etc I thought the label was a nice way to do it, but it backfired. Oh, zfsboot uses labels? The UFS partition editor never has, mostly for this reason. Sorry for spreading misinformation -- I'm not really familiar with the ZFS code. -Nathan ___ 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: diskid documentation
On 2014-06-02 18:40, Nathan Whitehorn wrote: > > On 06/02/14 15:32, Allan Jude wrote: >> On 2014-06-02 11:50, Kurt Lidl wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: > It also tends to sometimes hide the gpt label provider on me (not sure > in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. >>> I have seen this too, starting from a fresh install. >>> >>> The install process for stable/10 writes a /dev/gpt style label >>> into /etc/fstab for the swap space, and that never gets used, >>> because the /dev/diskid/ stuff appears to take precedence. >>> >>> I put the following into /boot/loader.conf to make the system more >>> sane: >>> >>> kern.geom.label.disk_ident.enable=0 >>> >>> -Kurt >>> >>> ___ >>> 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" >> I have a patch for the installer that solves this issue by explicitly >> using /dev/adaXpY or adaXsYb etc >> >> I thought the label was a nice way to do it, but it backfired. >> > > Oh, zfsboot uses labels? The UFS partition editor never has, mostly for > this reason. Sorry for spreading misinformation -- I'm not really > familiar with the ZFS code. > -Nathan > ___ > 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" It only used the labels for the fstab entry for swap. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: [patch] Switch to text mode during efi boot
Ed, Is there any progress about framebuffer corruption? Thanks, Huang Wenhui > 在 2014年5月22日，23:54，Ed Maste 写道： > >> On 22 May 2014 11:32, Rafael Espíndola wrote: >> The attached patch causes both boot1 and loader.efi to switch to text >> mode. This only >> seems to make a difference on Macs where otherwise no information was being >> displayed. >> >> The ConsoleControl.h file is copied from >> EdkCompatibilityPkg/Foundation/Protocol/ConsoleControl in >> https://github.com/tianocore/edk2. >> >> I tested that both programs are able to change to text mode by >> enabling only one of them at a time. >> >> With this patch I am able to see loaders output on all the macs I >> tried. The kernel boots correctly on a MacPro, but unfortunately it >> doesn't seem to be able to find the efi buffer in a MacBookPro. > > Great, thank you Rafael. There's framebuffer corruption issues on > some other hardware as well, so it may be that the eventual fix for > those will also solve the MBP issue. > >> Some design questions: >> >> * Why do we have both boot1 and loader? It is just the issue with >> building a usb image without root that requires having a boot1 that >> has a predictable size? > > No, boot1.efi only exists so that the loader and related Forth and > config files can be placed in a UFS root filesystem, as is done with > the x86 BIOS boot and on other platforms. This way the UEFI boot > easily integrates with the existing installer and tools. > > We could put the loader and files in the FAT EFI system partition > instead, but it would require more substantial changes in the > installer and system configuration. > >> * Even if we want to keep both boot1 and loader, could boot1 use libefi? > > I don't think there's any fundamental reason we couldn't. However, > we're going to need to take a broader look at reworking some of this > in the context of secure boot anyway (as we look at a signed shim > loader). > >> * Is it ok to always switch to text mode in libefi or should it >> provide a switch_to_text_mode function? > > I suspect it's fine / correct to always switch; we've just been > "lucky" that the current approach works with most firmwares. > ___ > 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"
RES: Select() vs Netmap
Hello, The code is built in the top of kipfw code, even if you remove the call to the 'ipfw packet parser' and leave only the loop there to forward the packets from one port to another, the problem also happens :) Sincerely, Fred Pedrisa -Mensagem original- De: Fred Pedrisa [mailto:fredhp...@hotmail.com] Enviada em: domingo, 1 de junho de 2014 15:16 Para: 'Luigi Rizzo' Cc: 'freebsd-current' Assunto: RES: Select() vs Netmap Hello, This is 1.4 Mpps (1.400.000 pps). There is a mix of src addresses, but one single dst address. Is there a way to disable rss maybe to check what happens ? -Mensagem original- De: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] Em nome de Luigi Rizzo Enviada em: domingo, 1 de junho de 2014 14:41 Para: Fred Pedrisa Cc: freebsd-current Assunto: Select() vs Netmap On Sunday, June 1, 2014, Fred Pedrisa > wrote: > Hey, guys. > > > > > > I'm currently experiencing a strange issue in my program (Using netmap). > > > > Sometimes, when I call select() in a FD, it gets like 4~8 packets per > event, however suddenly it drops to 1~2 packets per event, losing a > lot of performance and increasing the number of select calls necessary > to poll the NIC for new packets. > > > > Is there any type of tweak I can do, to make this behavior becomes > linear and sustain the performance in such case without these oscillations ? > > > > The behavior happens under the same stressing circumstances, around > 1.4 Mpps~ (64 byte packets). Is that one-point-four or fourteen? The firmer should be sustainable even with short batches. In any case apart from tweaking the interrupt moderation parameters in the device drivers, I'd check carefully the logic in your program and try to record a log of your activity. Average values rarely tell the full story of what is happening. see why you are srving small batches. One more thing, I think you use multuqueue, but no idea what kind of input traffic - whether it is all for the same destination or you have a mix of DST addresses. In the latter case, one thing to check is whether, on a restart of the program, the driver changes the hash key in the RSS filter. This might cause an imbalance in the traffic delivered to the queues. Cheers Luigi > > > > > Sincerely, > > > > Fred > > ___ > 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" > -- -+-- -+- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+-- -+- ___ 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"
