Re: fix pnpinfo on arch=amd64
On Sat Oct 23 10, Garrett Cooper wrote: On Sat, Oct 23, 2010 at 5:22 PM, Alexander Best arun...@freebsd.org wrote: this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any longer on arch=amd64. 1. I had to modify the Makefile to get it to work. probably because you built pnpinfo from contrib/pnpinfo and not from usr.sbin/pnpinfo. i'm not sure your changes to contrib/pnpinfo/Makefile are according to current practice. maybe the vendor Makefile shouldn't be modified and every additional stuff should rather go into usr.sbin/pnpinfo/Makefile. but i don't really know. also in the in usr.sbin/pnpinfo/makefile there's a check for PC98 that i'm not sure is really needed. 2. FWIW, I don't there's really much point in adding a check for only x86 architectures, if the tool is capable of more than that. yeah you're probably right. to be honest i know nothing about archs != i386|amd64. ;) so i just added the amd64 option, because i didn't want to break pnpinfo on other platforms. 3. Might as well close the file descriptor after opening it. right. expecially, because opening /dev/io (even in ro mode) is a huge security issue. so better close it asap. of course on i386/amd64 (maybe pc98 too?) i386_set_ioperm(2) could be used to work around the security issue. but since pnpinfo's job is to access hardware directly i think opening /dev/io directly can be consideren ok. SIGBUS occurs because it doesn't have permission to write via outb. It's a shame that there isn't a more proper way to catch this SIGBUS fault minus adding a SIGBUS handler (but that might have other undesired side effects). well on i386/amd (pc98?) you could use i386_get_ioperm(2) to check for proper io permissions. Thanks, -Garrett -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Slow disk access while rsync - what should I tune?
Hello, I have a web-server (nginx + apache + mysql, FreeBSD 7.3) with many sites. Every night it creates a backup of /home on a separate disk. /home is a RAID1 mirror on Adaptec 3405 (128M write cache) with SAS drives; /backup is a single SATA drive on the same controller. Rsync creates backups using hardlinks, it stores 7 daily and 4 weekly copies. Total amount of data is ~300G and 11M of files. The server is under heavy web load every time (appox 100 queries/sec). Every time backup starts server slows down significantly, disk operations become very slow. It may take up to 10 seconds to stat() a file that is not in filesystem cache. At the same time, rsync on remote server does not affect disk load much, server works without slowdown. I think that problem can be caused by two reasons: * either bulk of reads on SATA /backup drive, that fills OS filesystem cache and many file access operations require real disk read. * or bulk of writes on /backup fills controller write cache and geom disk operations queue grown, causing all disk operations to wait. This is only my assumption of course, I may be wrong. How can I find a real reason of these slowdowns, to either conclude that it is not possible to solve this because of hardware/software limits, or tune my software/hardware system to make this all work at an acceptable speed? Here is my current sysctl setup (what should I tune?): kern.maxvnodes=50 vfs.ufs.dirhash_maxmem=67108864 vfs.lookup_shared=1 kern.dirdelay=6 kern.metadelay=5 kern.filedelay=7 sysctl's counters (which others should I monitor?): vfs.numvnodes: 407690 vfs.ufs.dirhash_mem: 27158118 I tried to enable async (in hope it will make rsync faster) or even disable softupdates on /backup partition (in hope it will make rsync slower and OS filesytem cache will not be flushed by backups), it did not help. I also want to try to upgrate to Adaptec 5405 (it has 256M of write cache) or move mysql databases on a separate SAS disk, but I just not quite sure what will help better. What would I start from to diagnose the issue? Thanks in advance! -- // cronfy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Slow disk access while rsync - what should I tune?
On 24/10/2010 14:15, cronfy wrote: I tried to enable async (in hope it will make rsync faster) or even disable softupdates on /backup partition (in hope it will make rsync slower and OS filesytem cache will not be flushed by backups), it did not help. I also want to try to upgrate to Adaptec 5405 (it has 256M of write cache) or move mysql databases on a separate SAS disk, but I just not quite sure what will help better. rsync has standard options to limit the bandwidth it will consume. Making it write through a narrow pipe will also slow down the rate of disk accesses, so should help control the impact on other services on the machine. However, taking backups slowly makes it harder to ensure you have a consistent backup, so I recommend you investigate snapshotting the filesystem (well supported for UFS, trivially easy for ZFS) and then backup the snapshot as slowly as you like. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: Slow disk access while rsync - what should I tune?
On Sun, Oct 24, 2010 at 04:18:51PM +0100, Matthew Seaman wrote: However, taking backups slowly makes it harder to ensure you have a consistent backup, so I recommend you investigate snapshotting the filesystem (well supported for UFS, trivially easy for ZFS) and then backup the snapshot as slowly as you like. I'm not sure snapshots are so well supported for UFS. From sys/ufs/ffs/README.snapshot: As is detailed in the operational information below, snapshots are definitely alpha-test code and are NOT yet ready for production use. -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: fix pnpinfo on arch=amd64
On Sun, Oct 24, 2010 at 4:57 AM, Alexander Best arun...@freebsd.org wrote: On Sat Oct 23 10, Garrett Cooper wrote: On Sat, Oct 23, 2010 at 5:22 PM, Alexander Best arun...@freebsd.org wrote: this tiny patch will fix pnpinfo so it doesn't core dump (bus error) any longer on arch=amd64. 1. I had to modify the Makefile to get it to work. probably because you built pnpinfo from contrib/pnpinfo and not from usr.sbin/pnpinfo. i'm not sure your changes to contrib/pnpinfo/Makefile are according to current practice. maybe the vendor Makefile shouldn't be modified and every additional stuff should rather go into usr.sbin/pnpinfo/Makefile. but i don't really know. Ah... I was a bit confused as to why there was a copy hanging out in contrib, because it seems like it was imported primarily to FreeBSD in 2.2 (which contradicts the manpage as it states that it was imported in 7.2). I see it's over in DragonFly, but not in the other BSDs; it has a BSD license; doesn't denote any kind of proprietary info (leverages some of the FreeBSD isa(4) driver structures); doesn't have an external website for development; etc. I was also a bit confused why this directory wasn't iterated over in usr.sbin, but it appears to be missing from SUBDIR in usr.sbin/Makefile (wonder how many others are missing and whether or not the tools / apps really have any value, but that's another top for another thread). also in the in usr.sbin/pnpinfo/makefile there's a check for PC98 that i'm not sure is really needed. No, it's not used anymore (I looked over pnpinfo and the isa/machine headers). 2. FWIW, I don't there's really much point in adding a check for only x86 architectures, if the tool is capable of more than that. yeah you're probably right. to be honest i know nothing about archs != i386|amd64. ;) so i just added the amd64 option, because i didn't want to break pnpinfo on other platforms. Well, but there are other platforms, other than x86 that could benefit from using this tool (arm, mips, etc). There might be some bugs lurking in the code dealing with endianness, but that should be resolved first by enabling the tool for all platforms and fixing the cases one by one (unfortunately I don't have either architecture at my disposal, otherwise I'd test this out). I do have a Sparc64 pizza box that I could test this out on though later on this week... hmmm. 3. Might as well close the file descriptor after opening it. right. expecially, because opening /dev/io (even in ro mode) is a huge security issue. so better close it asap. of course on i386/amd64 (maybe pc98 too?) i386_set_ioperm(2) could be used to work around the security issue. but since pnpinfo's job is to access hardware directly i think opening /dev/io directly can be consideren ok. Well, right... but there's no reason to leak a filehandle until the program is finished :). SIGBUS occurs because it doesn't have permission to write via outb. It's a shame that there isn't a more proper way to catch this SIGBUS fault minus adding a SIGBUS handler (but that might have other undesired side effects). well on i386/amd (pc98?) you could use i386_get_ioperm(2) to check for proper io permissions. Yeah, and it's x86 specific. Kind of curious why there isn't a more generalized name for this API, but it appeared to be geared towards x86 (today, not so much according to LEGACY in io(4)). FWIW, it also looks like the manpages are missing for those syscalls, even though they're referenced in io(4)... $ man i386_get_ioperm No manual entry for i386_get_ioperm $ man i386_set_ioperm No manual entry for i386_set_ioperm ... and I couldn't find anything in the syscall entry table for this syscall. I did a bit more poking and it looks like the Linux ioperm syscall is the only really publicly available means of accessing this functionality. I could be wrong though. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
dump cache performance
Hello,
I took a look at the cache management for the dump command project on the
freebsd.org project ideas page.
http://www.freebsd.org/projects/ideas/ideas.html#p-extenddump
It appears that modifying dump to use a shared cache in a very simple way
(move the control structures to the shared segment and perform simple locking)
yields substantial speed increases.
A patch implementing this is attached.
Some numbers follow. The test system is an intel core i5 750, with recent
SATA disks. The tests all record an improvement with the shared cache, but
the values vary widely from 7% to 236%. It would be interesting to have
more tests on different configurations.
Would someone be interested in reviewing the patch and/or perform
more tests ?
Regards,
J.F. Dockes
Some tests results
===
The command used in all cases is dump -0aC XX -f /dev/null filesystem
The current dump actually uses 5 times the value of the -C option for
cache. The patched version uses a single shared memory segment. So olddump
-C 10 and newdump -C 50 are equivalent in terms of cache memory usage.
---
Tests performed on a small slice (3.7GB/4GB). The filesystem is quite full, and
has been pushed beyond full then partially pruned a few times to simulate
one which would actually had a life. It contains a mix of /home/ user
files (avg size 68 kB). Tests were run both in single disk and mirror mode.
Mirrored slice
Split cache -C 10: 18 MB/s
Shared cache -C 10 : 42 MB/s (+133%)
Same slice, without the mirroring
Split cache -C 10: 11 MB/s
Shared cache -C 50: 37 MB/s (+236%)
Tests on /var (500 MB / 5 GB). Mirrored slice
Split cache -C 10: 15 MB/s
Shared cache -C 50: 28 MB/s (+86%)
---
Tests on a bigger slice (24 GB / 43 GB) with mostly big files. Single disk
Split cache -C 10: 15 MB/s
Shared cache -C 50: 35 MB/s (+133%)
---
Tests on /usr (464 GB / 595 GB), mirrored
Split cache, -C 50: 57 MB/s
Shared cache, -C 250: 63 MB/s (+10%)
Level 1 tests (5GB dump)
Split cache, -C 50: 38 MB/s
Shared cache, -C 250: 41 MB/s (+7%)
diff -r 01d7ce8f41d5 cache.c
--- a/cache.c Wed Oct 20 08:39:03 2010 +0200
+++ b/cache.c Sun Oct 24 11:27:36 2010 +0200
@@ -9,6 +9,8 @@
#include sys/param.h
#include sys/stat.h
#include sys/mman.h
+#include sys/file.h
+#include fcntl.h
#ifdef sunos
#include sys/vnode.h
@@ -43,6 +45,8 @@
#define HFACTOR 4
#define BLKFACTOR 4
+static int lockfd;
+
static char *DataBase;
static Block **BlockHash;
static int BlockSize;
@@ -55,6 +59,15 @@
int i;
int hi;
Block *base;
+ int data_offs;
+ char tempname[20];
+
+ /* If mkstemp fails, we're back to using flock(), no need for special
+ action here */
+ strcpy(tempname, /tmp/dump.XX);
+ if ((lockfd = mkstemp(tempname)) = 0) {
+ unlink(tempname);
+ }
if ((BlockSize = sblock-fs_bsize * BLKFACTOR) MAXBSIZE)
BlockSize = MAXBSIZE;
@@ -64,10 +77,19 @@
msg(Cache %d MB, blocksize = %d\n,
NBlocks * BlockSize / (1024 * 1024), BlockSize);
- base = calloc(sizeof(Block), NBlocks);
- BlockHash = calloc(sizeof(Block *), HSize);
- DataBase = mmap(NULL, NBlocks * BlockSize,
- PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
+ data_offs = howmany(sizeof(Block) * NBlocks + sizeof(Block *) * HSize,
+ getpagesize()) * getpagesize();
+ DataBase = mmap(NULL, NBlocks * BlockSize + data_offs,
+ PROT_READ|PROT_WRITE, MAP_ANON|MAP_SHARED|MAP_NOSYNC,
+ -1, 0);
+ if (DataBase == MAP_FAILED) {
+ msg(mmap failed: %s\n, strerror(errno));
+ DataBase = NULL;
+ return;
+ }
+ BlockHash = (Block **)DataBase;
+ base = (Block *)(DataBase + HSize * sizeof(Block *));
+ DataBase += data_offs;
for (i = 0; i NBlocks; ++i) {
base[i].b_Data = DataBase + i * BlockSize;
base[i].b_Offset = (off_t)-1;
@@ -86,14 +108,18 @@
int hi;
int n;
off_t mask;
+ struct flock lock;
/*
* If the cache is disabled, or we do not yet know the filesystem
* block size, then revert to pread. Otherwise initialize the
* cache as necessary and continue.
+ * This will happen in the top process while mapping and needs no
+ * locking.
*/
- if (cachesize = 0 || sblock-fs_bsize == 0)
+ if (cachesize = 0 || sblock-fs_bsize == 0) {
return(pread(fd, buf, nbytes, offset));
+ }
if (DataBase == NULL)
cinit();
@@ -115,6 +141,20 @@
* occur near the end of the media).
*/
hi = (offset / BlockSize) % HSize;
+
+ /* Lock hash bucket */
+ lock.l_start = hi;
+ lock.l_len = 1;
+ lock.l_type = F_WRLCK;
+ lock.l_whence = SEEK_SET;
+
+ if (lockfd = 0 ? fcntl(lockfd, F_SETLKW, lock) :
+ flock(fd, LOCK_EX)) {
+ msg(shared cache lock failed: %s\n, strerror(errno));
+ return(pread(fd, buf, nbytes, offset));
+ }
+ lock.l_type = F_UNLCK;
+
pblk = BlockHash[hi];
ppblk = NULL;
while ((blk = *pblk) != NULL) {
@@ -138,8 +178,19 @@
*pblk = blk-b_HNext;
blk-b_HNext = BlockHash[hi];
BlockHash[hi] = blk;
+
+ if (lockfd = 0 ? fcntl(lockfd, F_SETLKW, lock) :
+
Re: Summary: Re: Spin down HDD after disk sync or before power off
Alexander Best wrote:
On Thu Oct 21 10, Dag-Erling Smørgrav wrote:
Alexander Best arun...@freebsd.org writes:
no need to get upset. you asked where i found the information regarding the
wear impact of spinning down disks and i gave you the answer.
I am upset by your claim that doing spin downs upon reboot might be
even worse than not doing spindowns upon shutdown, because you should
know better, and following your advice could damage people's hardware.
well...since currently hdds don't spindown during shutdown the current
behavior
is in fact damaging hardware. i don't quite understand why this hasn't been
fixed yet. the patch is available and known to work. it won't cause any
problems with SCSI devices like mav's current implementation, since the
spindown code is limited to ATA devices.
instead of talking and talking somebody should drop the changes into HEAD!
Comparing two ways implementing spindown, I've recalled that both of
them using xpt_polled_action() method, which depends on working
controller polling operation. So they could be almost equaly not good.
But the method present in HEAD now is more universal. Looking on fact
that need of spindown is not so obvious for SCSI devices (in SAN
environments), we can just make kern.cam.power_down tunable a bitmask of
supported protocols for now. Patch is attached.
But there is still question that stops me from going one way or another
now. Where all this this things should be done properly: in peripheral
driver, as proposed (then it have to be duplicated in da and ada drivers
and possibly some others), or at the transport level, as present,
independent from drivers? I am not sure, but have feeling that tape
drives (for example) may also benefit from head parking before powering
down.
--
Alexander Motin
--- cam_xpt.c.prev 2010-09-22 07:52:38.0 +0300
+++ cam_xpt.c 2010-10-24 18:50:13.0 +0300
@@ -153,7 +153,7 @@ static struct xpt_softc xsoftc;
TUNABLE_INT(kern.cam.boot_delay, xsoftc.boot_delay);
SYSCTL_INT(_kern_cam, OID_AUTO, boot_delay, CTLFLAG_RDTUN,
xsoftc.boot_delay, 0, Bus registration wait time);
-static int xpt_power_down = 0;
+static int xpt_power_down = 1;
TUNABLE_INT(kern.cam.power_down, xpt_power_down);
SYSCTL_INT(_kern_cam, OID_AUTO, power_down, CTLFLAG_RW,
xpt_power_down, 0, Power down devices on shutdown);
@@ -4646,11 +4646,16 @@ xpt_shutdown_dev(struct cam_ed *device,
return (1);
if (device-protocol == PROTO_ATA) {
+ if ((xpt_power_down 1) == 0)
+ return (1);
/* Only power down device if it supports power management. */
if ((device-ident_data.support.command1
ATA_SUPPORT_POWERMGT) == 0)
return (1);
- } else if (device-protocol != PROTO_SCSI)
+ } else if (device-protocol == PROTO_SCSI) {
+ if ((xpt_power_down 2) == 0)
+ return (1);
+ } else
return (1);
xpt_compile_path(path,
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Summary: Re: Spin down HDD after disk sync or before power off
On Sun, 24 Oct 2010 19:47:57 +0300 Alexander Motin m...@freebsd.org wrote: Comparing two ways implementing spindown, I've recalled that both of them using xpt_polled_action() method, which depends on working controller polling operation. So they could be almost equaly not good. But the method present in HEAD now is more universal. Looking on fact that need of spindown is not so obvious for SCSI devices (in SAN environments), we can just make kern.cam.power_down tunable a bitmask of supported protocols for now. Patch is attached. I've just committed the patch to move the functionality into ada(4). Should it be reverted? -- Bruce Cran ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Summary: Re: Spin down HDD after disk sync or before power off
Bruce Cran wrote: I've just committed the patch to move the functionality into ada(4). Should it be reverted? It seems to me that ATA and SCSI devices are sufficiently different (from the code's point of view) that it makes sense to separate the functionality in the ada and da drivers. In other words, I think the commit is good. I'm biased, though. By the way, I also think it's better to issue a standby immediate command, not a sleep command. The former is reversible, i.e. the drive can spin up if required (for whatever reason), while the latter may require a hardware reset, according to the documentation. 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 tricks is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure wink. -- Tim Peters ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Summary: Re: Spin down HDD after disk sync or before power off
Bruce Cran wrote: On Sun, 24 Oct 2010 19:47:57 +0300 Alexander Motin m...@freebsd.org wrote: Comparing two ways implementing spindown, I've recalled that both of them using xpt_polled_action() method, which depends on working controller polling operation. So they could be almost equaly not good. But the method present in HEAD now is more universal. Looking on fact that need of spindown is not so obvious for SCSI devices (in SAN environments), we can just make kern.cam.power_down tunable a bitmask of supported protocols for now. Patch is attached. I've just committed the patch to move the functionality into ada(4). Should it be reverted? Both solutions are possible. I don't have strong enough position to hurry now, when it is already done. It would be nice to hear opinion of SCSI people whether this functionality needed/safe there. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: fix pnpinfo on arch=amd64
On 10/24/10 11:14, Garrett Cooper wrote: well on i386/amd (pc98?) you could use i386_get_ioperm(2) to check for proper io permissions. Yeah, and it's x86 specific. Kind of curious why there isn't a more generalized name for this API, but it appeared to be geared towards x86 (today, not so much according to LEGACY in io(4)). That's because the whole concept is very x86-specific. For example, at least PowerPC and ARM don't even have a concept of IO space as distinct from memory, and /dev/io is something that only exists on i386, amd64, pc98, and ia64 (i.e. Intel products). -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Summary: Re: Spin down HDD after disk sync or before power off
On Sunday 24 October 2010 18:47:57 Alexander Motin wrote: I am not sure, but have feeling that tape drives (for example) may also benefit from head parking before powering down. USB hard disks would benefit as well I think. Although, ideally it should happen after unmounting the last file system. signature.asc Description: This is a digitally signed message part.
Re: Summary: Re: Spin down HDD after disk sync or before power off
Tijl Coosemans wrote: On Sunday 24 October 2010 18:47:57 Alexander Motin wrote: I am not sure, but have feeling that tape drives (for example) may also benefit from head parking before powering down. USB hard disks would benefit as well I think. Although, ideally it should happen after unmounting the last file system. Depending on unmount would be excessively aggressive. Far from every device close will be followed by unplugging. Same time nobody denies to run `camcontrol stop daX` before unplugging. USB disks are still da. It would be more interesting to know if this practice applicable to other kinds of SCSI devices. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Broadcom BCM4310 / bwi(4) and interface bwi0 is not showing up
I have a new laptop Acer Aspire One D250 and I want to install a
8-CURRENT as of CVS from May 2009 (as I use this on all my laptops).
The laptop comes with as Wifi chip:
none2 at pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4
rev=0x01 hdr=0x00
vendor = 'Broadcom Corporation'
device = 'BCM4310 USB Controller'
class = network
I learned after searching around that it should be supported by bwi(4)
and one should install the firmware kmod from the ports.
...
What I am missing here? Thanks
matthias
--
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e guru at unixarea.de - w http://www.unixarea.de/
Looking at bwi/if_bwi_pci.c, it doesn't seem as though your particular
chip is supported:
static const struct bwi_dev {
uint16_tvid;
uint16_tdid;
const char *desc;
} bwi_devices[] = {
{ PCI_VENDOR_BROADCOM, 0x4301,Broadcom BCM4301 802.11b Wireless Lan },
{ PCI_VENDOR_BROADCOM, 0x4307,Broadcom BCM4307 802.11b Wireless Lan },
{ PCI_VENDOR_BROADCOM, 0x4311,Broadcom BCM4311 802.11b/g Wireless Lan
},
{ PCI_VENDOR_BROADCOM, 0x4312,Broadcom BCM4312 802.11a/b/g Wireless
Lan },
{ PCI_VENDOR_BROADCOM, 0x4313,Broadcom BCM4312 802.11a Wireless Lan },
{ PCI_VENDOR_BROADCOM, 0x4320,Broadcom BCM4306 802.11b/g Wireless
Lan},
{ PCI_VENDOR_BROADCOM, 0x4321,Broadcom BCM4306 802.11a Wireless Lan},
{ PCI_VENDOR_BROADCOM, 0x4325,Broadcom BCM4306 802.11b/g Wireless
Lan},
{ PCI_VENDOR_BROADCOM, 0x4324,Broadcom BCM4309 802.11a/b/g Wireless
Lan },
{ PCI_VENDOR_BROADCOM, 0x4318,Broadcom BCM4318 802.11b/g Wireless Lan
},
{ PCI_VENDOR_BROADCOM, 0x4319,Broadcom BCM4318 802.11a/b/g Wireless
Lan },
{ PCI_VENDOR_BROADCOM, 0x431a,Broadcom BCM4318 802.11a Wireless Lan },
{ 0, 0, NULL }
};
-Mark
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Broadcom BCM4310 / bwi(4) and interface bwi0 is not showing up
El día Sunday, October 24, 2010 a las 07:48:15PM -0400, Mark Johnston escribió: none2 at pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4310 USB Controller' class = network I learned after searching around that it should be supported by bwi(4) and one should install the firmware kmod from the ports. ... What I am missing here? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e guru at unixarea.de - w http://www.unixarea.de/ Looking at bwi/if_bwi_pci.c, it doesn't seem as though your particular chip is supported: ... Yes, I saw this later too. And sys/dev/bwn does not compile in my old kernel env. I've pulled out now HEAD from SVN and will build an USB key based on this to see if it will have support for this chip. Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
