Re: st_dev and st_ino for pipes
On 2011-Oct-03 01:04:05 +0300, Kostik Belousov wrote: >Our implementation of pipes does not provide useful values for st_dev >and st_ino when stat(2) is done on an anonymous pipe. It was noted by the ... >Patch below implements the requirement, by the cost of the small overhead >at the pipe creation time, and slightly bigger cost at the destruction. Does it need to be so complex? This information isn't needed by the kernel and, to be "meaningful", all that is required is that the (st_dev,st_ino) pair is unique within the system. Given this, wouldn't it be sufficient to fake up a st_dev and then just make st_ino be a counter that starts from 0 and increments (atomically?) on every new pipe? No need to retain state or "free" anything when the pipe is destroyed. (If necessary, pick a new fake st_dev when st_ino wraps). >--- a/sys/kern/sys_pipe.c >+++ b/sys/kern/sys_pipe.c ... >+static ino_t pipedev_ino; .. >+ ub->st_dev = pipedev_ino; st_dev is a dev_t and hence pipedev_ino (which seems misnamed to me) should probably be dev_t rather than ino_t -- Peter Jeremy pgpBr4qBgTQzY.pgp Description: PGP signature
Re: x220 notes
On Mon, 3 Oct 2011, matt wrote: Ultimately, I think if we can set backlight, we can fix the screen after resume...I think it's just the backlight is low/off on resume... Can you use a very strong fronglight to see if this is actually the case? (Illumination angle may be important as well.) The state of the liquid crystal polarizing switches should be visible under sufficient illumination, and whether they change with input would be pretty definitive. I actually used to operate my iBook G4 in "frontlight mode" in bright sunlight for a while (until the wifi card flaked out, tying it to my desk). -Ben Kaduk ___ 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"
x220 notes
The saga continues: I see two major issues on this machine (which is great for a server os on a laptop :): 1. Screen brightness is not controllable/screen is off or backlight is 0 after resume I have tried suspend with a stripped down GENERIC (usb, wifi, ethernet, sound etc drivers all removed). This did not affect the outcome, the laptop resumes fine, but the screen is off. The is a noisy ACPI error about setting some PCIE stuff into D2...? (Oct 3 16:51:45 sylph kernel: pci0: failed to set ACPI power state D2 on \_SB_.PCI0.EXP7: AE_BAD_PARAMETER) I have investigated acpi_video...I can't seem to get it to do anything on this machine, although all the ACPI handles it looks for are present. sysctl hw.acpi.video.lcd0.active=1 does (0 => 0), and brightness changes have no effect. xset dpms force off && sleep 2 && xset dpms force on actually does work, the only thing which does. dpms.ko does not work. xbacklight finds no screens. acpi_ibm does attach with LEN0068 added as an ID, but setting brightness suddenly causes correct fan speed, around 1950rpm to become 65535 rpm...I think this might be close to the fix. The acpidump (I have posted it here:https://docs.google.com/leaf?id=0B6YlMzJxarGbYjE4OTgzYjYtOTQ1OC00YWU3LWE0MGItZDk1MmZiMDIxNTRh&hl=en_US) actually checks for FreeBSD during OSI. Doesn't seem to help. I can't seem to make either acpi_ibm or acpi_video adjust the backlight although both seem to think they can. Ultimately, I think if we can set backlight, we can fix the screen after resume...I think it's just the backlight is low/off on resume... 2. psm does not detect synaptics click pad To make matters worse, xf86-input-synaptics doesn't like it either. I have seen some linux posts where the device probe for PS/2 was disrupting it (psm?) and xf86-input-synaptics says "found mouse model 0 instead" This of course is simply annoying and not as annoying as broken screens! There are other small things that may I have not cared to test such as fingerprint reader and camera card reader. Matt ___ 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: cvsup broken on amd64?
On 4 October 2011 05:53, Maxime Henrion wrote: > Great, that's a relief. I knew the pthread library was free to wake a > thread up even if it hadn't been signaled, which is why one always has > to call pthread_cond_wait() inside of a while() loop checking for the > condition, but wasn't sure about that particular scenario, so I'm glad > to hear a confirmation. Thanks! So shall I commit your change, if someone hasn't already? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-BETA3 Available...
Hi, On Wed, Sep 28, 2011 at 9:42 PM, Ken Smith wrote: > > The third BETA build of the 9.0-RELEASE release cycle is now > available. Since this is the first release of a brand new branch > I cross-post the announcements on both -current and -stable. But > just so you know most of the developers active in head pay more > attention to the -current mailing list. If you notice problems you > can report them through the normal Gnats PR system or on the -current > mailing list. > > The 9.0-RELEASE cycle will be tracked here: > > http://wiki.freebsd.org/Releng/9.0TODO > could you please update that page ? It's wayy out of date... Thanks, - Arnaud > though the schedule listed there is still way off. We'll re-work the > schedule some time soon. > > NOTE: The location of the FTP install tree and ISOs is the same as it > had been for BETA2, though we are still deciding if this will be the > layout we switch to for the release. > > ISO images for the following architectures are available, with pathnames > given relative to the top-level of the FTP site: > > amd64: .../releases/amd64/amd64/ISO-IMAGES/9.0/ > i386: .../releases/i386/i386/ISO-IMAGES/9.0/ > ia64: .../releases/ia64/ia64/ISO-IMAGES/9.0/ > powerpc: .../releases/powerpc/powerpc/ISO-IMAGES/9.0/ > powerpc64: .../releases/powerpc/powerpc64/ISO-IMAGES/9.0/ > sparc64: .../releases/sparc64/sparc64/ISO-IMAGES/9.0/ > > MD5/SHA256 checksums are tacked on below. > > If you would like to use csup/cvsup mechanisms to access the source > tree the branch tag to use is now "RELENG_8", if you use "." (head) > you will get 10-CURRENT. If you would like to access the source tree > via SVN it is "svn://svn.freebsd.org/base/stable/9/". We still have > the nit that the creation of a new SVN branch winds up causing what > looks like a check-in of the entire tree in CVS (a side-effect of the > svn2cvs exporter) so "mergemaster -F" is your friend if you are using > csup/cvsup. > > At this point FreeBSD-Update is still not available, in part to help > encourage testing the installer. > > We hope to start the Release Candidate phase of the release cycle with > the next test build. > > Checksums: > > MD5 (FreeBSD-9.0-BETA3-amd64-bootonly.iso) = 2ce7b93d28fd7ff37965893f1af3f7fc > MD5 (FreeBSD-9.0-BETA3-amd64-dvd1.iso) = 4affc701f2052edc548274f090e49235 > MD5 (FreeBSD-9.0-BETA3-amd64-memstick.img) = e260f2f2122326cb9a93ac83eb006c1c > > MD5 (FreeBSD-9.0-BETA3-i386-bootonly.iso) = ef43977dbf1c8c0f40710985660ed55e > MD5 (FreeBSD-9.0-BETA3-i386-dvd1.iso) = 95bc3b0c312b83a79752dce616075cdb > MD5 (FreeBSD-9.0-BETA3-i386-memstick.img) = d86475510e34698e8077edac717ae73c > > MD5 (FreeBSD-9.0-BETA3-ia64-bootonly.iso) = 463ee0447dd96ab7fc6e61a6b4623128 > MD5 (FreeBSD-9.0-BETA3-ia64-memstick) = 0d6ed910294fbf0afc1c34e9a55227b8 > MD5 (FreeBSD-9.0-BETA3-ia64-release.iso) = 716ace96755ddc2965c76590253fb756 > > MD5 (FreeBSD-9.0-BETA3-powerpc-bootonly.iso) = > 6110fe69b92e40e4eab03167795459d0 > MD5 (FreeBSD-9.0-BETA3-powerpc-memstick) = 9a365252f3c347c0b465096aed383679 > MD5 (FreeBSD-9.0-BETA3-powerpc-release.iso) = 8c18ca00a9a8013a615c86c2a5df46be > > MD5 (FreeBSD-9.0-BETA3-powerpc64-bootonly.iso) = > 2d9e2458116de2b89085fe416e3ce2d5 > MD5 (FreeBSD-9.0-BETA3-powerpc64-memstick) = 0b547b0375bfb2a53efc2185b61bfc63 > MD5 (FreeBSD-9.0-BETA3-powerpc64-release.iso) = > cbc4ad7477bae80f0055e116038d06c2 > > MD5 (FreeBSD-9.0-BETA3-sparc64-bootonly.iso) = > cc1d53cbae4a00672bc0cce3e11ba956 > MD5 (FreeBSD-9.0-BETA3-sparc64-dvd1.iso) = 988b07e44a4cfeb39e0aca0a1239c2d2 > > SHA256 (FreeBSD-9.0-BETA3-amd64-bootonly.iso) = > bd12e94d69c189efa15f4ccc5c98d552d54ed204d6d811e9ac8a965dc8780c42 > SHA256 (FreeBSD-9.0-BETA3-amd64-dvd1.iso) = > fd026f1d0bdddaff533a58b8c731ecbc2b2b14d9d975e8771bebe07eba7a579c > SHA256 (FreeBSD-9.0-BETA3-amd64-memstick.img) = > 963326cc20ce81cfde062651d757fca1da2ae313fcb2aafcd92054970fdff3a6 > > SHA256 (FreeBSD-9.0-BETA3-i386-bootonly.iso) = > 8a083b9859ca09eca944afc9b20e93b167861b5d876a6ff2c791ad7ffe18f2ac > SHA256 (FreeBSD-9.0-BETA3-i386-dvd1.iso) = > 811e66efc14ba1a6184b787b09eb497df3c72f38688f73e6b44ffce9e8b81b42 > SHA256 (FreeBSD-9.0-BETA3-i386-memstick.img) = > 8aca989b1c2837a21240a6c58124f19576cb322c183242e222999f59d99e6293 > > SHA256 (FreeBSD-9.0-BETA3-ia64-bootonly.iso) = > 96c91419fd9a80ff5c3322ef3ee99a4608bda3b39a630dca07869a2aa9c82f13 > SHA256 (FreeBSD-9.0-BETA3-ia64-memstick) = > 3d253650fdd0bcbecd4f0fb45844f65f4e5a89120b66d16c2d3828370488d5fa > SHA256 (FreeBSD-9.0-BETA3-ia64-release.iso) = > ab8d322bedc28329298b520b1550940dc5ae75a04636f326baf0f9f5d7e933e2 > > SHA256 (FreeBSD-9.0-BETA3-powerpc-bootonly.iso) = > 0fa3930add2b054ccc828ef9fbbec90efcd9781ad3c82a5ad8bae2d533f27cc5 > SHA256 (FreeBSD-9.0-BETA3-powerpc-memstick) = > d2c6e43d47021716ac3d0956acc5b9ecf0cf26bc452c1cdf7033d32dc2a66289 > SHA256 (FreeBSD-9.0-BETA3-powerpc-release.iso) = > 9791766756ecaaa536c2f4e12f86fa99d8fc248d1457f36adafaf2a8865c95b2 > > SHA256 (FreeBSD-9.0-BETA3-powerpc64-boo
Re: Strange ZFS filesystem corruption
On Mon, Oct 3, 2011 at 11:21 AM, Paul Mather wrote: > = > > The pool itself reports no errors. I performed a scrub on the pool yet this > bizarre filesystem corruption persists: > > = > tape# zpool status backups > pool: backups > state: ONLINE > scan: scrub repaired 15K in 7h33m with 0 errors on Sat Oct 1 19:22:35 2011 The pool *did* report 15K errors that it was able to repair. I'd start with testing your RAM with memtest86 or memtest86+. ZFS errors without reported checksum errors may be the sign of bad memory. I.e. data gets corrupted before ZFS gets to calculate checksum and later invalid data with valid checksum gets written to disk. --Artem ___ 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: cvsup broken on amd64?
On Mon, Oct 3, 2011 at 11:30 PM, Jilles Tjoelker wrote:
> On Mon, Oct 03, 2011 at 06:15:41PM +0200, Maxime Henrion wrote:
>> Knowing all that, what's happening seems quite clear. If
>> fixups_close() is called while there was still fixup requests pending,
>> those should be processed by the detailer thread before it returns.
>> Subsequent fixups_get() call should continue returning pending items,
>> until there are no more entries in the queue _and_ the queue is
>> closed.
>
>> So, line 144 in fixups.c (in fixups_get()):
>
>> if (f->closed) {
>
>> should actually be:
>
>> if (f->closed && f->size == 0) {
>
> That looks sensible.
>
>> The fact that this could even happen smells a bit weird to me though;
>> it means the detailer thread didn't get a chance to run between some
>> item was added to the queue (fixups_put() signals the detailer thread
>> via pthread_cond_signal()), and that it only runs now that the updater
>> queue has been closed. I wouldn't go as far as saying this is a bug,
>> but is it even valid for the pthread library to "coalesce" two
>> pthread_cond_signal() calls into one when the thread didn't get to run
>> since the first call was made? If so, then the above fix is perfectly
>> valid. If not, there is a deeper bug in the threading library, or in
>> the CVS mode code which I didn't write (but that seems far-fetched).
>
> The pthread library is free to "coalesce" pthread_cond_signal() calls
> like that. This is because a thread awakened by pthread_cond_signal()
> (or any other event) is not guaranteed to start running immediately and
> pthread_cond_signal() does nothing if there is no thread to wake up.
Great, that's a relief. I knew the pthread library was free to wake a
thread up even if it hadn't been signaled, which is why one always has
to call pthread_cond_wait() inside of a while() loop checking for the
condition, but wasn't sure about that particular scenario, so I'm glad
to hear a confirmation. Thanks!
Cheers,
Maxime
___
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: cvsup broken on amd64?
On Mon, Oct 03, 2011 at 06:15:41PM +0200, Maxime Henrion wrote:
> Knowing all that, what's happening seems quite clear. If
> fixups_close() is called while there was still fixup requests pending,
> those should be processed by the detailer thread before it returns.
> Subsequent fixups_get() call should continue returning pending items,
> until there are no more entries in the queue _and_ the queue is
> closed.
> So, line 144 in fixups.c (in fixups_get()):
> if (f->closed) {
> should actually be:
> if (f->closed && f->size == 0) {
That looks sensible.
> The fact that this could even happen smells a bit weird to me though;
> it means the detailer thread didn't get a chance to run between some
> item was added to the queue (fixups_put() signals the detailer thread
> via pthread_cond_signal()), and that it only runs now that the updater
> queue has been closed. I wouldn't go as far as saying this is a bug,
> but is it even valid for the pthread library to "coalesce" two
> pthread_cond_signal() calls into one when the thread didn't get to run
> since the first call was made? If so, then the above fix is perfectly
> valid. If not, there is a deeper bug in the threading library, or in
> the CVS mode code which I didn't write (but that seems far-fetched).
The pthread library is free to "coalesce" pthread_cond_signal() calls
like that. This is because a thread awakened by pthread_cond_signal()
(or any other event) is not guaranteed to start running immediately and
pthread_cond_signal() does nothing if there is no thread to wake up.
If there is no second CPU core available to run the detailer thread, it
is more efficient to have the updater thread do some more work before
incurring a context switch.
--
Jilles Tjoelker
___
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: SCSI descriptor sense changes, testing needed
This has been committed to head, and the plan is to get it into stable/9 in time for 9.0. Please let me know if you run into any problems with the changes. Thanks, Ken On Fri, Sep 30, 2011 at 23:19:14 -0600, Kenneth D. Merry wrote: > > I have attached a new version of the patches, with a number of changes. > > One issue that has cropped up is that the previous sense code and my new > descriptor sense changes never paid any attention to the actual length of > the sense data returned by the controller. > > I have changed all of the error recovery code and sense printing code to > honor the sense data length in the CAM CCB. > > One other problem related to that is that many controller drivers don't set > the sense residual field in struct ccb_scsiio properly, or don't set it at > all. This patch includes changes to the isp, mps, mpt, umass, and ciss > drivers to set the sense_resid field properly. > > There are lots of other drivers in the system, however, that haven't been > audited, and may or may not set the sense residual correctly. > > I also fixed an issue reported by Fabian Keil that showed up with the ahci > driver. In reverting a change I have in my local tree to switch to a 2 > byte length field in the SCSI inquiry CDB, I accidently shortened the CDB > to 5 bytes. Oops. > > I'd really appreciate more feedback; Fabian is the only person to report > testing the previous patch. > > Thanks, > > Ken > > On Thu, Sep 22, 2011 at 13:33:05 -0600, Kenneth D. Merry wrote: > > > > I have attached a set of patches against head that implement SCSI > > descriptor sense support for CAM. > > > > Descriptor sense is a new sense (SCSI error) format introduced in the SPC-3 > > spec in 2006. FreeBSD doesn't currently support it. > > > > Seagate's new 3TB SAS drives come with descriptor sense enabled by default, > > and it's possible that other newer drives do as well. Because all the > > sense key, additional sense code, and additional sense code qualifier > > fields are in different places, the CAM error recovery code will not do the > > right thing when it gets descriptor sense. > > > > These patches do bump up the size of struct scsi_sense_data, and so I have > > incremented CAM_VERSION as well. I have discussed this with re@, and it > > looks like we'll be putting the changes in before 9.0, so it ships with > > support for newer SCSI devices. > > > > A number of things have changed in these patches, but in particular, it > > would be good to test the following: > > > > - The sa(4) (SCSI tape) driver. The residual handling code, which looks > >at the sense data, has changed. > > - The Playstation 3 CDROM driver. > > - Firewire target mode. > > - umass devices with the NO_INQUIRY_EVPD quirk. > > > > Also, please let me know if you see any anomalies with the sense printing > > code. In the common cases the output should look identical to the old > > code, but in some cases it will be a little different. e.g.: > > > > # camcontrol inquiry da40 -v > > pass47: Fixed Direct Access SCSI-6 device > > pass47: Serial Number 9XK0GAJ7S125XDNU > > pass47: 300.000MB/s transfers, Command Queueing Enabled > > > > (Seagate 3TB drive) > > > > # camcontrol modepage da40 -m 10 |grep D_SENSE > > D_SENSE: 1 > > > > (Descriptor sense is enabled) > > > > # camcontrol modepage da40 -m 15 -v > > (pass47:mps1:0:47:0): MODE SENSE(6). CDB: 1a 0 4f 0 ff 0 > > (pass47:mps1:0:47:0): CAM status: SCSI Status Error > > (pass47:mps1:0:47:0): SCSI status: Check Condition > > (pass47:mps1:0:47:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field > > in CDB) > > (pass47:mps1:0:47:0): Field Replaceable Unit: 1 > > (pass47:mps1:0:47:0): Command byte 2 bit 5 is invalid > > (pass47:mps1:0:47:0): Descriptor 0x80: 00 00 00 00 00 00 00 00 00 00 00 00 > > 00 00 > > camcontrol: error sending mode sense command > > > > (The FRU and Sense Key Specific entries are on separate lines, and a > > vendor-specific sense descriptor is printed out in hex format.) > > > > Anyway, I'd appreciate any testing and feedback on these changes. As I > > said, they will probably be in 9.0, so if there are any issues it would be > > better to find them now. :) > > > > Thanks, > > > > Ken > > -- > > Kenneth Merry > > k...@freebsd.org > -- > Kenneth Merry > k...@freebsd.org -- Kenneth Merry k...@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"
Strange ZFS filesystem corruption
I wasn't sure whether to post this here or on sta...@freebsd.org. The system now runs RELENG_9, but the ZFS pool exhibiting problems was created, IIRC, under 9-CURRENT. I believe RELENG_9 is sufficiently close to HEAD at this stage that this list is probably the correct place for this message. I have a raidz2 ZFS pool on a system that I have recently been using as a mirror for about 6.5 TiB of data. The data are mirrored nightly using rsync. I noticed during these nightly rsync copies I would get some errors like this: = file has vanished: "/backups/storage/san/DLA/DLA_Records/05DLAAdmin" rsync: stat "/backups/storage/san/DLA/DLA_Records/05DLAAdmin" failed: No such file or directory (2) rsync: recv_generator: mkdir "/backups/storage/san/DLA/DLA_Records/05DLAAdmin/05DI_business copy" failed: No such file or directory (2) *** Skipping any contents from this failed directory *** = It appears that 05DLAAdmin is a directory that is corrupted. It shows in an "ls" but any attempt to descend into that directory or discern its attributes fails with a "No such file or directory" error. Furthermore, I cannot delete this directory (even with "rm -rf"). E.g.: = tape# pwd /backups/storage/san/DLA tape# whoami root tape# rm -rf DLA_Records rm: DLA_Records/07DLAAdmin/07Digital_Imaging_Work: Directory not empty rm: DLA_Records/07DLAAdmin/FY07IAWAprep: Directory not empty rm: DLA_Records/07DLAAdmin: Directory not empty rm: DLA_Records: Directory not empty tape# cd DLA_Records tape# ls 05DLAAdmin 07DLAAdmin tape# ls -l ls: 05DLAAdmin: No such file or directory total 3 drwxrws--- 4 500 501 4 Oct 3 11:53 07DLAAdmin tape# file 05DLAAdmin 05DLAAdmin: cannot open `05DLAAdmin' (No such file or directory) tape# ls -R 07DLAAdmin 07Digital_Imaging_Work FY07IAWAprep 07DLAAdmin/07Digital_Imaging_Work: ls: 07Proposals: No such file or directory 07DLAAdmin/FY07IAWAprep: ls: Budget: No such file or directory tape# ls 07DLAAdmin 07Digital_Imaging_Work FY07IAWAprep tape# ls 07DLAAdmin/07Digital_Imaging_Work 07Proposals tape# ls -l 07DLAAdmin/07Digital_Imaging_Work/07Proposals ls: 07DLAAdmin/07Digital_Imaging_Work/07Proposals: No such file or directory tape# ls 07DLAAdmin/FY07IAWAprep Budget tape# ls 07DLAAdmin/FY07IAWAprep/Budget ls: 07DLAAdmin/FY07IAWAprep/Budget: No such file or directory tape# file 07DLAAdmin/FY07IAWAprep/Budget 07DLAAdmin/FY07IAWAprep/Budget: cannot open `07DLAAdmin/FY07IAWAprep/Budget' (No such file or directory) tape# cd 05DLAAdmin 05DLAAdmin: No such file or directory. = The pool itself reports no errors. I performed a scrub on the pool yet this bizarre filesystem corruption persists: = tape# zpool status backups pool: backups state: ONLINE scan: scrub repaired 15K in 7h33m with 0 errors on Sat Oct 1 19:22:35 2011 config: NAMESTATE READ WRITE CKSUM backups ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 gpt/disk02 ONLINE 0 0 0 gpt/disk03 ONLINE 0 0 0 gpt/disk04 ONLINE 0 0 0 gpt/disk05 ONLINE 0 0 0 gpt/disk06 ONLINE 0 0 0 gpt/disk07 ONLINE 0 0 0 errors: No known data errors tape# uname -a FreeBSD tape.private.lib.vt.edu 9.0-BETA3 FreeBSD 9.0-BETA3 #0: Wed Sep 28 15:18:59 EDT 2011 pmat...@tape.private.lib.vt.edu:/usr/obj/usr/src/sys/TAPE amd64 tape# zpool get all backups NAME PROPERTY VALUE SOURCE backups size 10.9T - backups capacity 62% - backups altroot- default backups health ONLINE - backups guid 1352318175125790395 default backups version28 default backups bootfs - default backups delegation on default backups autoreplaceoff default backups cachefile - default backups failmode waitdefault backups listsnapshots off default backups autoexpand off default backups dedupditto 0 default backups dedupratio 1.00x - backups free 4.07T - backups allocated 6.80T - backups readonly off - tape# zfs get all backups/storage NAME PROPERTY VALUE SOURCE backups/storage type filesystem - backups/storage creation Fri Sep 2 14:43 2011 - backups/storage used 4.26T - backups/storage available 2.60T - backups/storage referenced4.26T - backups/storage compressratio 1.51x - backups/storage mounted yes- backups/storage quota none default backups/storage reservation none
Re: FreeBSD 9: Fn+* keyboard combinations aren't working anymore.
On Mon, Oct 3, 2011 at 8:56 PM, matt wrote: > /usr/src/sys/dev/acpi_support/acpi_asus.c > > Might be a good place to start? > > You can use 'acpidump -dt > acpidump.aml' to get a dump of the laptop's > acpi in the file acpidump.aml...This may allow you to determine what > changed, either in the acpi_asus or in your laptop's ACPI > > Matt > If that acpi_asus.c file is from acpi_asus.ko, then it has nothing to do with my problem - i'm not using it. I will take a look on acpidump, thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9: Fn+* keyboard combinations aren't working anymore.
On Sun, 2 Oct 2011 15:49:44 +0400 arrowdodger <6year...@gmail.com> wrote: > On Wed, Sep 28, 2011 at 5:44 PM, arrowdodger <6year...@gmail.com> > wrote: > > > On Wed, Sep 28, 2011 at 5:32 PM, Lars Engels > > wrote: > > > >> On Wed, Sep 28, 2011 at 05:30:25PM +0400, arrowdodger wrote: > >> > Hello. I've used FreeBSD 8-STABLE on my Asus K40IN notebook. This > >> notebook > >> > has an key combination (Fn+F6/F7)to change monitor brightness. > >> > After > >> i've > >> > updated my system to 9-STABLE, these combinations stopped > >> > working. It's worth mentioning, that these combinations still > >> > work at boot screen. > >> > >> Have you tried loading acpi_asus.ko? > >> > > > > I've tried to do so when i was on 8-STABLE and it didn't work. It's > > not working for me on 9-STABLE too: > > acpi_asus0: Unsupported Asus laptop: K40IN > > > > All hotkeys, except ones for switching Wi-Fi and adjusting volume, > > were working on 8-STABLE. > > > > If no one knows a fix for this problem, maybe someone can point me to > relevant code? I may try to bisect revisions, or to check commit log. > ___ > 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" /usr/src/sys/dev/acpi_support/acpi_asus.c Might be a good place to start? You can use 'acpidump -dt > acpidump.aml' to get a dump of the laptop's acpi in the file acpidump.aml...This may allow you to determine what changed, either in the acpi_asus or in your laptop's ACPI Matt ___ 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: cvsup broken on amd64?
On Mon, Sep 19, 2011 at 8:26 AM, Adrian Chadd wrote:
> 2011/9/19 Alexander Zagrebin :
>
>> I've tried this patch. Now csup "hangs" before handling fixups.
>> So there is no message "Applying fixups..." at all.
>
> Wow. Hm. Where's the author when one needs them..
Well that's quite a strange coincidence. I haven't read current@ in
ages and now I just stumble upon this. :-)
It's been a long time since I've been looking at this code but the
patch from the original PR seems /nearly/ correct, while the one from
adrian@ is definitely incorrect. But to be honest, this part of the
CVSup protocol is a lot more twisted than it would seem, plus a
comment of mine was definitely misleading (it should say that the
detailer thread will hang, not the lister one). Here are some
explanations that should help clarify things.
When the updater thread encountered a problem in updating a file (MD5
checksum doesn't match), it will send a fixup "request" to the
detailer thread. The detailer thread then sends this request to the
CVSup server, which, finally, sends the whole file for the _updater_
thread to receive. So what's happening at this position in the code is
that the updater thread finished processing all the "normal" updates,
and thus knows there won't be any more fixup requests (fixups
themselves can't generate other fixups). This is why it closes the
writing end of the fixups queue, to wake up the detailer thread which
will notice the closed state and the absence of fixups in the queue,
and will thus terminate. So we _have_ to call fixups_close() here, or
the detailer thread will block indefinitely in fixups_get() when an
error happened.
Knowing all that, what's happening seems quite clear. If
fixups_close() is called while there was still fixup requests pending,
those should be processed by the detailer thread before it returns.
Subsequent fixups_get() call should continue returning pending items,
until there are no more entries in the queue _and_ the queue is
closed.
So, line 144 in fixups.c (in fixups_get()):
if (f->closed) {
should actually be:
if (f->closed && f->size == 0) {
The fact that this could even happen smells a bit weird to me though;
it means the detailer thread didn't get a chance to run between some
item was added to the queue (fixups_put() signals the detailer thread
via pthread_cond_signal()), and that it only runs now that the updater
queue has been closed. I wouldn't go as far as saying this is a bug,
but is it even valid for the pthread library to "coalesce" two
pthread_cond_signal() calls into one when the thread didn't get to run
since the first call was made? If so, then the above fix is perfectly
valid. If not, there is a deeper bug in the threading library, or in
the CVS mode code which I didn't write (but that seems far-fetched).
It would be great to fix my misleading comment too by the way :-)
I hope this helps.
Cheers,
Maxime
___
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: SCSI descriptor sense changes, testing needed
"Kenneth D. Merry" wrote: > On Tue, Sep 27, 2011 at 21:46:03 +0200, Fabian Keil wrote: > > "Kenneth D. Merry" wrote: > > > > > On Sat, Sep 24, 2011 at 21:27:22 +0200, Fabian Keil wrote: > > > > "Kenneth D. Merry" wrote: > > > > > > > > > I have attached a set of patches against head that implement SCSI > > > > > descriptor sense support for CAM. > > > > > > > > > Anyway, I'd appreciate any testing and feedback on these changes. As > > > > > I > > > > > said, they will probably be in 9.0, so if there are any issues it > > > > > would > > > > > be better to find them now. :) > > > > > > > > I've been using the patch on a ThinkPad R500 since yesterday and > > > > just reverted it today again to get my kernel closer to HEAD before > > > > looking into some (probably unrelated) panics. > > > > > > > > I didn't notice it while using the patch, but it looks like the > > > > kernel wasn't able to pick up cd0 anymore: > > > > > > Hmm. I don't think any of the changes would have caused this, but > > > evidently something did... > > > > > > Let's see if we can debug it... > > > > > > I have attached a patch to add some debugging output, and I see at least > > > one interesting thing in the logs below. > > > > > > Can you re-apply the descriptor sense patch, and then try the attached > > > debugging patch as well? > > > > Sure. > > I believe this is fixed with my latest set of patches. Can you try them > and let me know? The device is indeed properly picked up now: Oct 3 12:09:26 r500 kernel: ahcich0: AHCI reset... Oct 3 12:09:26 r500 kernel: ahcich0: SATA connect time=900us status=0113 Oct 3 12:09:26 r500 kernel: ahcich0: AHCI reset: device found Oct 3 12:09:26 r500 kernel: ahcich1: AHCI reset... Oct 3 12:09:26 r500 kernel: ahcich1: SATA connect time=1000us status=0113 Oct 3 12:09:26 r500 kernel: ahcich1: AHCI reset: device found Oct 3 12:09:26 r500 kernel: ugen0.1: at usbus0 Oct 3 12:09:26 r500 kernel: uhub0: on usbus0 Oct 3 12:09:26 r500 kernel: ugen1.1: at usbus1 Oct 3 12:09:26 r500 kernel: uhub1: on usbus1 Oct 3 12:09:26 r500 kernel: ugen2.1: at usbus2 Oct 3 12:09:26 r500 kernel: uhub2: on usbus2 Oct 3 12:09:26 r500 kernel: ugen3.1: at usbus3 Oct 3 12:09:26 r500 kernel: uhub3: on usbus3 Oct 3 12:09:26 r500 kernel: ugen4.1: at usbus4 Oct 3 12:09:26 r500 kernel: uhub4: on usbus4 Oct 3 12:09:26 r500 kernel: ugen5.1: at usbus5 Oct 3 12:09:26 r500 kernel: uhub5: on usbus5 Oct 3 12:09:26 r500 kernel: ugen6.1: at usbus6 Oct 3 12:09:26 r500 kernel: uhub6: on usbus6 Oct 3 12:09:26 r500 kernel: ugen7.1: at usbus7 Oct 3 12:09:26 r500 kernel: uhub7: on usbus7 Oct 3 12:09:26 r500 kernel: battery0: battery initialization start Oct 3 12:09:26 r500 kernel: acpi_acad0: acline initialization start Oct 3 12:09:26 r500 kernel: battery0: battery initialization done, tried 1 times Oct 3 12:09:26 r500 kernel: acpi_acad0: On Line Oct 3 12:09:26 r500 kernel: acpi_acad0: acline initialization done, tried 1 times Oct 3 12:09:26 r500 kernel: ahcich0: AHCI reset: device ready after 100ms Oct 3 12:09:26 r500 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: Oct 3 12:09:26 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Oct 3 12:09:26 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Oct 3 12:09:26 r500 kernel: GEOM: new disk ada0 Oct 3 12:09:26 r500 kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 Oct 3 12:09:26 r500 kernel: ada0: ATA-8 SATA 1.x device Oct 3 12:09:26 r500 kernel: ada0: Serial Number 090509FB2F32LLEY6D8A Oct 3 12:09:26 r500 kernel: ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) Oct 3 12:09:26 r500 kernel: ada0: Command Queueing enabled Oct 3 12:09:26 r500 kernel: ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) Oct 3 12:09:26 r500 kernel: ada0: Previously was known as ad4 Oct 3 12:09:26 r500 kernel: pass0 at ahcich0 bus 0 scbus0 target 0 lun 0 Oct 3 12:09:26 r500 kernel: pass0: ATA-8 SATA 1.x device Oct 3 12:09:26 r500 kernel: pass0: Serial Number 090509FB2F32LLEY6D8A Oct 3 12:09:26 r500 kernel: pass0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) Oct 3 12:09:26 r500 kernel: pass0: Command Queueing enabled Oct 3 12:09:26 r500 kernel: pass1 at ahcich1 bus 0 scbus1 target 0 lun 0 Oct 3 12:09:26 r500 kernel: pass1: Removable CD-ROM SCSI-0 device Oct 3 12:09:26 r500 kernel: pass1: Serial Number M2R96NC0647 Oct 3 12:09:26 r500 kernel: pass1: 150.000MB/s transfers (SATA 1.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) Oct 3 12:09:26 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status error Oct 3 12:09:26 r500 kernel: (cd0:ahcich1:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Oct 3 12:09:26 r500 kernel: (cd0:ahcich1:0:0:0): CAM status: SCSI Status Error Oct 3 12:09:26 r500 kernel: (cd0:ahcich1:0:0:0): SCSI status: Check Condition Oct 3 12:09:26 r500 kernel: (cd0:ahcich1:0:0:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) Oct 3 12:09:26 r500
Re: code in GEOM thread could not use vnode API (Was: alq_open_flags() panics in _mtx_lock_flags())
Hello, Current. You wrote 2 октября 2011 г., 23:14:59: > It seems, that error only occurs when I call alq API from geom > threads (from g_events, for example). Module, which is not GEOM > class, could use this API without any problem! > Is it normal, that GEOM could not use vnode API? Is it normal, that > this leads to panic, and not some diagnostic messages, even with > WITNESS and other diagnostic options turned on? not holding (explicitly release before call) topology lock doesn't help. -- // Black Lion AKA Lev Serebryakov ___ 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"
