Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless
On 13 Mar 2010, at 14:00, PseudoCylon wrote: - Original Message From: Rui Paulo rpa...@gmail.com To: Weongyo Jeong weon...@freebsd.org Cc: PseudoCylon moonlightak...@yahoo.ca; Alexander Egorenkov egore...@googlemail.com ; freebsd-current@freebsd.org Sent: Fri, March 12, 2010 7:42:46 PM Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless On 13 Mar 2010, at 09:18, Weongyo Jeong wrote: Out of curiosity, what's the difference between run(4) and rt2870 driver written by Alexander Egorenkov? And why there are two drivers? The thread says it all. Just need to go though some pages. His user name is egorenar. http://forums.freebsd.org/showthread.php?s=1d3b01fbed80c61ff508e12e9805146et=7562 From what I understand, Alexander's driver supports 11n ann run(4) doesn't. That's correct. Besides run(4) supports rt3XXX chipsets. Oh, I see. I think we really need to start working on merging the two... -- Rui Paulo ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
On 13 Mar 2010, at 16:36, Hans Petter Selasky wrote: On Saturday 13 March 2010 03:42:46 Rui Paulo wrote: On 13 Mar 2010, at 09:18, Weongyo Jeong wrote: On Thu, Mar 04, 2010 at 12:50:29AM -0800, PseudoCylon wrote: Hello, Finally, I have fixed mysterious device lock out and run(4) works fine in HOSTAP mode. Up time is 80 hours and counting. I even filed tax though it. The device supports up to 253 stations. I only tested with 2 station. If you have resources, please hit it with bunch of STAs. As usual codes are posted at my git repository git://dev.nasreddine.com/run.git http://dev.nasreddine.com/gitweb/?p=run.git;a=summary Please fetch 'hostap_rc' branch not 'master' this time. or freebsd forums http://forums.freebsd.org/showthread.php?s=1d3b01fbed80c61ff508e12e98051 46et=7562 Out of curiosity, what's the difference between run(4) and rt2870 driver written by Alexander Egorenkov? And why there are two drivers? From what I understand, Alexander's driver supports 11n ann run(4) doesn't. Will this two drivers be merged then? I hope so. -- Rui Paulo ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
Later i also plan to add multi BSS support so upto 8 HOSTAPs, several STAs and WDSs will be possible with rt2860 and rt2870 on FreeBSD 8. On Sat, Mar 13, 2010 at 9:24 AM, Rui Paulo rpa...@gmail.com wrote: On 13 Mar 2010, at 16:36, Hans Petter Selasky wrote: On Saturday 13 March 2010 03:42:46 Rui Paulo wrote: On 13 Mar 2010, at 09:18, Weongyo Jeong wrote: On Thu, Mar 04, 2010 at 12:50:29AM -0800, PseudoCylon wrote: Hello, Finally, I have fixed mysterious device lock out and run(4) works fine in HOSTAP mode. Up time is 80 hours and counting. I even filed tax though it. The device supports up to 253 stations. I only tested with 2 station. If you have resources, please hit it with bunch of STAs. As usual codes are posted at my git repository git://dev.nasreddine.com/run.git http://dev.nasreddine.com/gitweb/?p=run.git;a=summary Please fetch 'hostap_rc' branch not 'master' this time. or freebsd forums http://forums.freebsd.org/showthread.php?s=1d3b01fbed80c61ff508e12e98051 46et=7562 Out of curiosity, what's the difference between run(4) and rt2870 driver written by Alexander Egorenkov? And why there are two drivers? From what I understand, Alexander's driver supports 11n ann run(4) doesn't. Will this two drivers be merged then? I hope so. -- Rui Paulo ___ 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: Amanda, FreeBSD8, amtype, hairpulling, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12.03.2010 15:20, Svein Skogen wrote: I'm having trouble getting Amanda (2.6.1p2 from ports) to play nicely with my hardware. Devices are: HP Ultrium 3-SCSI Q25W at scbus0 target 1 lun 0 (sa0,pass0) HP 1x8 G2 AUTOLDR 2.80 at scbus0 target 1 lun 1 (pass1,ch0) connected via: mpt0: LSILogic SAS/SATA Adapter port 0x9000-0x90ff mem 0xfe4fc000-0xfe4f,0xfe4e-0xfe4e irq 16 at device 0.0 on pci2 mpt0: [ITHREAD] mpt0: MPI Version=1.5.20.0 os and number in question is: FreeBSD storage.stillbilde.net 8.0-STABLE FreeBSD 8.0-STABLE #0: Tue Mar 9 07:01:59 UTC 2010 sv...@storage.stillbilde.net:/usr/obj/usr/src/sys/GENERIC amd64 Tapes are regular LTO-3 (HP C7973A). amtapetype simply hangs (after writing 3-4 tps for 5 seconds, then simple silence both on sa0 and console) Has anybody run into this problem with FreeBSD8+mpt+autoloader? //Svein I'm finally starting to make sense of what I'm seeing (hence the crossposting) Seems I've stumbled onto some strange incompatibility between my SAS controller (LSI 3801E), Tape-library, and FreeBSD+Solaris. The behavior I'm seeing is consistent with this solaris bug: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6894775 but luckily (?) for me, my disks are on an MFI controller. I'm seeing the exact same behavior in both FreeBSD and OpenSolaris 133 and 134. Linux and Windows installs on the box (this box is currently being set up, so I'm rather liberated from reinstall-concerns) seems unaffected, atleast the HP Software doesn't fail the way tar/dump/dd/amanda/bacula/whatnot does at random intervals. The errors only occur when the device I'm reading/writing from is 100% laoded (reading or writing 56mb/sec + compression), which when fed from a raid capable of more than 6 times that is quite likely to happen during backups. The Solaris bug seems to be around MSI handling, but there are several reports over there about this error occuring even with MSI disabled. Right now I'm dumbstruck about this, and might install Linux just to get backups up and running this year, because I'm too tired of this entire process, but I'd REALLY rather run FreeBSD or OpenSolaris. This is based on a personal preference and nothing else, but if anybody has some blinding insights on how to get this working, I'm open for suggestions. //Svein - -- - +---+--- /\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE - +---+--- If you really are in a hurry, mail me at svein-mob...@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - Picture Gallery: https://gallery.stillbilde.net/v/svein/ - -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkubtf8ACgkQODUnwSLUlKTfGgCgndwhQdAjFjlUp2jCh5POr0jp 0rYAoKUsR2AjzlBCM/eqMfUjGfKtWXof =2lnD -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: dev.bce.X.com_no_buffers increasing and packet loss
David Christensen wrote: Pyun YongHyeon wrote: On Wed, Mar 10, 2010 at 02:45:47PM -0800, David Christensen wrote: The bce(4) hardware supports a linked list of pages for RX buffer=20 descriptors. The stock build supports 2 pages (RX_PAGES) with a=20 total of 511 BD's per page. The hardware can support a=20 maximum of=20 64K BD's but that would be an unnecessarily large amount of mbufs=20 for an infrequent problem. =20 I think that depends on how you define infrequent. Our use=20 case is a largish core router. It's highly likely that we'll=20 see this again and again in various packet storms on our network. =20 Are the packet storms always always from the same host or do they come from multiple hosts? The hardware supports RSS which can spread the network load across multiple receive queues and multiple CPU cores, but only when the traffic is spread across several hosts. (The current bce(4) driver doesn't include support for RSS.) If a storm of small frames comes from a single host then almost all adapters will be challenged to handle the flow. In this case the storm only involved 2 hosts. While it's an exceptional circumstance it isn't unusual in our environment (core router in a datacenter). Fortuately we controlled both machines in this instance. Perhaps if the load is spread across more CPUs, then perhaps only those flows unlucky to hash to the CPU handling the storm will be degraded. That is a marginally better situation than all flows being degraded. From the sounds of it RSS isn't the cure for this particular situation, but may improve performance in general. It does sound like reworking the buffer will solve the problem. Perhaps having a 2 recieve rings so that once one ring is available for processing, the other ready filled and clear ring can be used for recieving frames. Ian -- Ian Freislich ___ 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
buildkernel broken
Hi, I'm trying to build kernel (update from 204272 to 205122) and got following error: === drm/i915 (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/b450/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/b450 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c: In function 'i915_dma_cleanup': /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:159: error: 'DEV' undeclared (first use in this function) /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:159: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:159: error: for each function it appears in.) /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c: In function 'i915_set_status_page': /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:807: error: 'DEV' undeclared (first use in this function) /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c: In function 'i915_driver_load': /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:847: error: 'DEV' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/modules/drm/i915. *** Error code 1 Stop in /usr/src/sys/modules/drm. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/b450. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- wbr, tiger ___ 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: buildkernel broken
On Sat, 2010-03-13 at 19:35 +0200, Sergey V. Dyatko wrote: Hi, I'm trying to build kernel (update from 204272 to 205122) and got following error: === drm/i915 (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/b450/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/b450 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c: In function 'i915_dma_cleanup': /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:159: error: 'DEV' undeclared (first use in this Typo, pointyhat to me... Fixed in rev 205126. robert. function) /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:159: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:159: error: for each function it appears in.) /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c: In function 'i915_set_status_page': /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:807: error: 'DEV' undeclared (first use in this function) /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c: In function 'i915_driver_load': /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:847: error: 'DEV' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/modules/drm/i915. *** Error code 1 Stop in /usr/src/sys/modules/drm. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/b450. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- wbr, tiger ___ 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 -- Robert Noland rnol...@freebsd.org FreeBSD ___ 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
build failures after stdlib update
Hello Current, I am wondering if someone could help me please. I built the 9.0-current kernel and world while there was still a bug in the updated strlen(). Unfortunately this rendered the machine unbootable as gptzfsloader crashed and would just echo an endless stream of spaces across the screen. After booting off another drive and reverting the gptzfsboot to the .old version, I was able to being the machine back to life, but applications were dieing left and right (Signal 10). I used dgb to find the offending library /lib/libc.so.7 and had a copy of the library from 3 days ago. After reverting that library, I was able to start all my applications OK and the machine is working.. However. I am not able to build the latest world (I havent tried kernel yet). Whenever I start gengtype dies with a signal 10. I have tried to use dgb to examine the core file, but it gives me nonsense answers so I am not able to locate what library it might be trying to use. I have also tried to blow away the /usr/src and /usr/obj directories and recreate them from svn just incase there was something hanging on from the previous build. Can anyone give me advice on how to track this problem down or fix it? I suspect I still have a lib that still trying to use the broken libc.so.7 or something else depended on it, but I am not sure.. Thanks, Peg ___ 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: A tool for remapping bad sectors in CURRENT?
Dag-Erling Smørgrav wrote: Miroslav Lachman000.f...@quip.cz writes: Yes, rewriting by dd or any other way works for reallocating or clearing pending sectors counter, but in server environment In a server environment, you'd be a fool not to have some sort of redundancy set up. I am using gmirror on low-end servers, so rewriting some sectors on one disk drive is useless and in this case I prefer resync of the whole gmirror (but it is log run - about 10 hours on busy server) I need to know the affected file, as it can be for example database file and then it is a big problem! Rewriting the sector inside InnoDB ib_data file can cause DB crash, data loss etc. How is that different from *not* rewriting the sector? If there's a bad sector somewhere in your data, your database is still going to crash. It is not about different, it is about I need to know the affected file to know what actions should be taken. If it is some logfile, I can delete it and then rewrite the sector. If it is some normal unchanged file, I can restore it from backup, if it is database file, I must take some special action. For example, stop DB engine, try to repair/fix the DB file, dump restore etc. So the first step is to find what file is affected, then take some action AND rewrite the sector by dd to reallocate the sector. (or replace the drive) So... can somebody with enough knowledge write some docs / script how to find the affected file based on LBA read error from messages / SMART log? Miroslav Lachman ___ 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: build failures after stdlib update
On Sat, Mar 13, 2010 at 10:31 AM, Pegasus Mc Cleaft k...@mthelicon.com wrote: Hello Current, I am wondering if someone could help me please. I built the 9.0-current kernel and world while there was still a bug in the updated strlen(). Unfortunately this rendered the machine unbootable as gptzfsloader crashed and would just echo an endless stream of spaces across the screen. After booting off another drive and reverting the gptzfsboot to the .old version, I was able to being the machine back to life, but applications were dieing left and right (Signal 10). I used dgb to find the offending library /lib/libc.so.7 and had a copy of the library from 3 days ago. After reverting that library, I was able to start all my applications OK and the machine is working.. However. I am not able to build the latest world (I havent tried kernel yet). Whenever I start gengtype dies with a signal 10. I have tried to use dgb to examine the core file, but it gives me nonsense answers so I am not able to locate what library it might be trying to use. I have also tried to blow away the /usr/src and /usr/obj directories and recreate them from svn just incase there was something hanging on from the previous build. Can anyone give me advice on how to track this problem down or fix it? I suspect I still have a lib that still trying to use the broken libc.so.7 or something else depended on it, but I am not sure.. Some of the items in this commit may be causing the bad juju you're seeing on the screen: http://svn.freebsd.org/changeset/base/205021 Please try reverting that and see how things go. Thanks! -Garrett ___ 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: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Fri, 12 Mar 2010 15:13:34 -0800 Weongyo Jeong weongyo.je...@gmail.com wrote: I thought that your opinion was right and if mem is 0xf400-0xf4003fff (16 Kb) I thought the device has 4 cores. However it looks this was wrong according to the below document: http://voodoowarez.com/bcm5365p.pdf Please see Section 3: PCI Core, PCI Bus (Page 34) that it indicates that 16Kb, maybe 8 Kb in the old devices is core register region. Accesses to the lower half of the core register region are translated into system backplane accesses using the PCIBAR0Window register Accesses to offsets 0x1000 to 0x17FF of this region initiate a direct access to the external SPROM If we just access memory using offset + core and bus_space_read_x interfaces it would actually not access core register region. So without solving this problem it looks it could not remove coreswitch routines. regards, Weongyo Jeong Hi, this document about SoC BCM5365P, not about PCI device with PCI to SSB bridge. I know in SoC`s like BSM5365 (I test it in BCM5354 and BCM5836) core switching is not required. BCM5354 - http://lists.freebsd.org/pipermail/freebsd-mips/2009-June/000421.html BCM5836 - http://lists.freebsd.org/pipermail/freebsd-mips/2010-February/000635.html With PCI device, when device report memory window 0xf400-0xf4003fff, why we can`t use full window? May be You can test your code without core switching? -- Alex RAY r...@ddteam.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: A tool for remapping bad sectors in CURRENT?
Miroslav Lachman 000.f...@quip.cz writes: So... can somebody with enough knowledge write some docs / script how to find the affected file based on LBA read error from messages / SMART log? ZFS will tell you straight away, but I guess if you used ZFS, you wouldn't be asking :) For FFS, you can unmount the file system (boot from a CD or memory stick or whatever if that file system is / or /usr), run fsdb on the failing disk, use findblk to look up the inode number for the file that contains the bad sector. Note that you have to convert the LBA to an offset relative to the start of the partition. Unfortunately, you can't easily go from inode to file name; you have to mount the file system and use something like find -inum. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?
On Sat, Mar 13, 2010 at 4:33 AM, Garrett Cooper yanef...@gmail.com wrote: On Wed, Mar 10, 2010 at 9:58 PM, Garrett Cooper yanef...@gmail.c Apart from the typo above (s/ctrl/ctlr/), things work appropriately Oopss I'm sorry. now at reboot. The only problem is that bootup is really wonky now, because the RAID had a LOT of issues attaching to cam(4) (failed in 2/3 cold boot attempts); an additional branch condition may need to be added to the above if-statement if this change didn't take that into account. However, if the old behavior was incorrect and the new behavior is correct, s.t. the RAID controller demonstrating bus detection timeout issue that is occurring with a lot of USB devices and some RAID controllers today, this could be extremely problematic. if you don't mind could you try this patch? Less dirty but always quick :) Thank you for your time. -- Gianni diff -r 69c84861a227 sys/dev/twa/tw_cl.h --- a/sys/dev/twa/tw_cl.h Thu Mar 11 16:18:11 2010 -0500 +++ b/sys/dev/twa/tw_cl.h Sat Mar 13 18:50:16 2010 -0500 @@ -66,6 +66,8 @@ #define TW_CLI_CTLR_STATE_RESET_PHASE1_IN_PROGRESS (15) /* G66 register write access bug needs to be worked around. */ #define TW_CLI_CTLR_STATE_G66_WORKAROUND_NEEDED(16) +/* Controller is shutting down. */ +#define TW_CLI_CTLR_STATE_SHUTDOWN_IN_PROGRESS (17) /* Possible values of ctlr-ioctl_lock.lock. */ #define TW_CLI_LOCK_FREE 0x0 /* lock is free */ diff -r 69c84861a227 sys/dev/twa/tw_cl_init.c --- a/sys/dev/twa/tw_cl_init.c Thu Mar 11 16:18:11 2010 -0500 +++ b/sys/dev/twa/tw_cl_init.c Sat Mar 13 18:50:16 2010 -0500 @@ -598,6 +598,7 @@ tw_cl_shutdown_ctlr(struct tw_cl_ctlr_ha * and notify the controller that we are going down. */ ctlr-state = ~TW_CLI_CTLR_STATE_ACTIVE; + ctlr-state |= TW_CLI_CTLR_STATE_SHUTDOWN_IN_PROGRESS; tw_cli_disable_interrupts(ctlr); diff -r 69c84861a227 sys/dev/twa/tw_cl_intr.c --- a/sys/dev/twa/tw_cl_intr.c Thu Mar 11 16:18:11 2010 -0500 +++ b/sys/dev/twa/tw_cl_intr.c Sat Mar 13 18:50:16 2010 -0500 @@ -75,9 +75,12 @@ tw_cl_interrupt(struct tw_cl_ctlr_handle if (ctlr == NULL) goto out; - /* If we get an interrupt while resetting, it is a shared - one for another device, so just bail */ - if (ctlr-state TW_CLI_CTLR_STATE_RESET_IN_PROGRESS) + /* +* If we get an interrupt while resetting or shutting down, +* it is a shared one for another device, so just bail +*/ + if (ctlr-state TW_CLI_CTLR_STATE_RESET_IN_PROGRESS || + ctlr-state TW_CLI_CTLR_STATE_SHUTDOWN_IN_PROGRESS) goto out; /* ___ 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: build failures after stdlib update
Can anyone give me advice on how to track this problem down or fix it? I suspect I still have a lib that still trying to use the broken libc.so.7 or something else depended on it, but I am not sure.. Some of the items in this commit may be causing the bad juju you're seeing on the screen: http://svn.freebsd.org/changeset/base/205021 Please try reverting that and see how things go. Hi Garrett, I'm not exactly sure if I can. I can use the svn utility OK, but the build looks like it is dieing when it makes the /usr/obj/usr/src/gnu/usr.bin/cc/cc_tools/* stuff. I was able to progress the build a little further by coping the build binaries from the /usr/obj/tmp/usr/../cc/cc_tools directory and then continuing the build with a NO_CLEAN. I found that the binaries that were dieing were statically linked and the ones that worked were dynamically linked to /lib/libc.so.7. I thought I was able to push through the problem, but it died later on with pages of bad references: (single example below) /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(cfgexpand.o) (.text+0xc6d): In function `add_reg_br_prob_note': : undefined reference to `gen_rtx_EXPR_LIST' I havent tried rolling back the sources yet, but I will give it a try. My suspicion is that the build will die because I have some library with a bug in it still. One option I was thinking of is copying in all the old libraries in /lib and seeing if it will build then. Do you think that will be helpfull? Peg ___ 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: Problem with new bwn driver on -CURRENT
On Mon, 2010-03-08 at 17:33 -0800, Weongyo Jeong wrote: Thank you for dmesg. It looks you are right that your device in PIO mode doesn't work. Specially RX path is weird that it was good until the status is changed to RUN but after querying DHCP requests (or another) there were no more RX events (seems no more frames ready). I think it'd be better to file a PR because I could not test LP PHY easily and it looks that it takes time to solve this problem. Could you please do that? Done. http://www.freebsd.org/cgi/query-pr.cgi?pr=144724 Thanks for looking into it. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
On Sat, Mar 13, 2010 at 11:12:05PM +0200, Alex RAY wrote: On Fri, 12 Mar 2010 15:13:34 -0800 Weongyo Jeong weongyo.je...@gmail.com wrote: I thought that your opinion was right and if mem is 0xf400-0xf4003fff (16 Kb) I thought the device has 4 cores. However it looks this was wrong according to the below document: http://voodoowarez.com/bcm5365p.pdf Please see Section 3: PCI Core, PCI Bus (Page 34) that it indicates that 16Kb, maybe 8 Kb in the old devices is core register region. Accesses to the lower half of the core register region are translated into system backplane accesses using the PCIBAR0Window register Accesses to offsets 0x1000 to 0x17FF of this region initiate a direct access to the external SPROM If we just access memory using offset + core and bus_space_read_x interfaces it would actually not access core register region. So without solving this problem it looks it could not remove coreswitch routines. regards, Weongyo Jeong Hi, this document about SoC BCM5365P, not about PCI device with PCI to SSB bridge. Yes it's about SoC BCM5365P but I think the basic concept of Silicon Backplane would be same at a PCI device with PCI to SSB bridge. I know in SoC`s like BSM5365 (I test it in BCM5354 and BCM5836) core switching is not required. BCM5354 - http://lists.freebsd.org/pipermail/freebsd-mips/2009-June/000421.html BCM5836 - http://lists.freebsd.org/pipermail/freebsd-mips/2010-February/000635.html The above URLs you mentioned indicates that siba0: Sonics SiliconBackplane rev 0x0 at mem 0x1800-0x18006fff on nexus0 siba_cc0: ChipCommon core at mem 0x1800-0x18000fff irq 0 on siba0 bfe0: Broadcom 44xx Ethernet Chip at mem 0x18001000-0x18001fff irq 1 on siba0 siba_mips0: MIPS 3302 processor at mem 0x18002000-0x18002fff on siba0 ohci0: SiBa integrated USB controller at mem 0x18003000-0x18003fff irq 4 on siba0 siba0 used memory region at starting 0x1800 that I think this is a reason why it doesn't require core switching and each cores have their own memory region at starting 0x1800. But in a case of PCI device with PCI to SSB bridge, it normally used 0xf400, 0xfe20 or other address which reserved by parent PCI bridge. With PCI device, when device report memory window 0xf400-0xf4003fff, why we can`t use full window? Because I'm not a Silicon Backplane expert I could not answer this question. But I'd like to make sure that memory window at 0xf400 (size 16 Kbytes) comes from PCI BAR0 when pci(4) attached device. Moreover I believe size of memory window also comes from PCI BAR0 size testing of pci(4). Of course I think we can try to remap full memory window after calculating numbers of core but it looks meaning would be little bit different. May be You can test your code without core switching? I tried to remove core switching code in siba_bwn bridge but after moment I got stuck to go forward. For example, I have 1 device which attached with bwn(4) and it has 4 cores: 0x1800-0x18000fff ChipCommon 0x18001000-0x18001fff EMAC 0x18002000-0x18002fff PCI 0x18003000-0x18003fff PCMCIA When it attached at siba_bwn it shows its memory region at 0xfe2fe000 - 0xfe2f (8 Kbytes). Initial PCI BAR0 value was 0x18002000. If your opinion is right the memory region for full window should be 0xfe2fe000 - 0xfe301fff (16 Kb for 4 core, each core consumes 0x1000 size) Even if I tried to remap memory region from 0xfe2fe000 to 0xfe301fff and setting PCI BAR0 to 0x1800, another problem is occurred for reading SPROM data. To access external SPROM it could be possible to access bus_space_read_2(bt, bh, 0x1000 ~ 0x17ff) at ChipCommon core. But accessing register in a core could not over 0xfff because maximum size of a core limited within 0x1000. That means internally in Silicon Backplane it has a special meaning if it try to access over 0x1000 or 0x2000 which mentioned a quote at Section 3: PCI Core, PCI Bus (Page 34). I guess you're thinking that we could access EMAC core using bus_space_read_2(bt, bh, 0x1000 ~ 0x1fff) after setting full memory window. But it looks it's not possible. regards, Weongyo Jeong ___ 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: CALL for TEST [HOSTAP] run(4) ralink usb wireless
On Sat, Mar 13, 2010 at 08:36:41AM +0100, Hans Petter Selasky wrote: On Saturday 13 March 2010 03:42:46 Rui Paulo wrote: On 13 Mar 2010, at 09:18, Weongyo Jeong wrote: On Thu, Mar 04, 2010 at 12:50:29AM -0800, PseudoCylon wrote: Hello, Finally, I have fixed mysterious device lock out and run(4) works fine in HOSTAP mode. Up time is 80 hours and counting. I even filed tax though it. The device supports up to 253 stations. I only tested with 2 station. If you have resources, please hit it with bunch of STAs. As usual codes are posted at my git repository git://dev.nasreddine.com/run.git http://dev.nasreddine.com/gitweb/?p=run.git;a=summary Please fetch 'hostap_rc' branch not 'master' this time. or freebsd forums http://forums.freebsd.org/showthread.php?s=1d3b01fbed80c61ff508e12e98051 46et=7562 Out of curiosity, what's the difference between run(4) and rt2870 driver written by Alexander Egorenkov? And why there are two drivers? From what I understand, Alexander's driver supports 11n ann run(4) doesn't. Will this two drivers be merged then? I really want it and hope driver writers focus on one driver for same chipsets. :-) regards, Weongyo Jeong ___ 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: ZFS allows deletion of files in a sticky directory
On Fri, 19 Feb 2010 18:23, alexz@ wrote: I have found that directory entry may be deleted from a ZFS directory with the sticky bit, if the entry is a plain file and you have write access (this is citation from a comments in zfs_dir.c) But this behavior isn't described in the sticky(8) and isn't allowed on a UFS. The attached patch provides the UFS-like behavior of a sticky directories on a ZFS. Is this bug or feature? Perhaps you have removed a directory on a share that is managed through Samba and somehow you have had a ACL entry that allowed you to remove that directory ?. This patch is unsuitable for implementation. It effectively removes ACL access for determining writes to a object that you have ACL write access to. Regards, -- jhell ___ 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: [PATCH] newvers.sh
In message: 20100312171206.ga31...@dragon.nuxi.org
David O'Brien obr...@freebsd.org writes:
: * Simplify SRCDIR calculation by directly finding the kernel sources
: based directly on one of them.
:
: Reviewed by: dhw
:
: This change does not increase the kernel build time. It also continues
: to restrict the revision to just the kernel sources, and not the whole
: tree.
:
: Timing tests by: dhw
patch omitted
David,
I have a better simplification, I think, that works for me for each of
the tests that I've done (both traditional and buildkernel builds).
The Makefile already knows where the kernel src is located. Let's use
that knowledge to make things a little simpler. This also uses the
Makefile variable SYSDIR. It should also work with non-standard sys
directories.
There's one divergence between svn and git tagging: svn does src/sys,
while git does src. This is how the previous code was before, and I
don't think I've changed that.
Can you confirm this works for you and also comment on the change
itself? It is a bigger change, but results in a simpler (I think)
newvers.sh.
Comments?
Warner
Index: conf/kern.post.mk
===
--- conf/kern.post.mk (revision 204938)
+++ conf/kern.post.mk (working copy)
@@ -244,7 +244,7 @@
${NORMAL_LINT}
vers.c: $S/conf/newvers.sh $S/sys/param.h ${SYSTEM_DEP}
- MAKE=${MAKE} sh $S/conf/newvers.sh ${KERN_IDENT}
+ MAKE=${MAKE} SYSDIR=$S sh $S/conf/newvers.sh ${KERN_IDENT}
vnode_if.c: $S/tools/vnode_if.awk $S/kern/vnode_if.src
${AWK} -f $S/tools/vnode_if.awk $S/kern/vnode_if.src -c
Index: conf/newvers.sh
===
--- conf/newvers.sh (revision 204938)
+++ conf/newvers.sh (working copy)
@@ -44,7 +44,7 @@
${PARAMFILE})
else
RELDATE=$(awk '/__FreeBSD_version.*propagated to newvers/ {print $3}' \
- $(dirname $0)/../sys/param.h)
+ ${SYSDIR}/sys/param.h)
fi
@@ -84,54 +84,46 @@
fi
touch version
-v=`cat version` u=${USER:-root} d=`pwd` h=${HOSTNAME:-`hostname`} t=`date`
+v=`cat version` u=${USER:-root} h=${HOSTNAME:-`hostname`} t=`date`
i=`${MAKE:-make} -V KERN_IDENT`
-case $d in
-*/sys/*)
- SRCDIR=${d##*obj}
- if [ -n $MACHINE ]; then
- SRCDIR=${SRCDIR##/$MACHINE}
+for dir in /bin /usr/bin /usr/local/bin; do
+ if [ -d ${SYSDIR}/.svn -a -x ${dir}/svnversion ] ; then
+ svnversion=${dir}/svnversion
+ break
fi
- SRCDIR=${SRCDIR%%/sys/*}
+ if [ -d ${SYSDIR}/../.git -a -x ${dir}/git ] ; then
+ git_cmd=${dir}/git --git-dir=${SYSDIR}/../.git
+ break
+ fi
+done
- for dir in /bin /usr/bin /usr/local/bin; do
- if [ -d ${SRCDIR}/sys/.svn -a -x ${dir}/svnversion ] ; then
- svnversion=${dir}/svnversion
- break
- fi
- if [ -d ${SRCDIR}/.git -a -x ${dir}/git ] ; then
- git_cmd=${dir}/git --git-dir=${SRCDIR}/.git
- break
- fi
- done
+if [ -n $svnversion ] ; then
+echo $svnversion
+ svn= r`cd ${SYSDIR} $svnversion`
+fi
- if [ -n $svnversion ] ; then
- svn= r`cd ${SRCDIR}/sys $svnversion`
- fi
- if [ -n $git_cmd ] ; then
- git=`$git_cmd rev-parse --verify --short HEAD 2/dev/null`
- svn=`$git_cmd svn find-rev $git 2/dev/null`
- if [ -n $svn ] ; then
+if [ -n $git_cmd ] ; then
+ git=`$git_cmd rev-parse --verify --short HEAD 2/dev/null`
+ svn=`$git_cmd svn find-rev $git 2/dev/null`
+ if [ -n $svn ] ; then
+ svn= r${svn}
+ git==${git}
+ else
+ svn=`$git_cmd log | fgrep 'git-svn-id:' | head -1 | \
+sed -n 's/^...@\([0-9][0-9]*\).*$/\1/p'`
+ if [ -n $svn ] ; then
svn= r${svn}
- git==${git}
+ git=+${git}
else
- svn=`$git_cmd log | fgrep 'git-svn-id:' | head -1 | \
-sed -n 's/^...@\([0-9][0-9]*\).*$/\1/p'`
- if [ -n $svn ] ; then
- svn= r${svn}
- git=+${git}
- else
- git= ${git}
- fi
+ git= ${git}
fi
- if $git_cmd --work-tree=${SRCDIR} diff-index \
- --name-only HEAD | read dummy; then
- git=${git}-dirty
- fi
fi
- ;;
-esac
+ if $git_cmd --work-tree=${SYSDIR}/.. diff-index \
+ --name-only HEAD | read dummy; then
+ git=${git}-dirty
+ fi
+fi
cat EOF vers.c
