Compat symlinks for /dev/acd0?
Hi, When the ATA_CAM option is enabled in the kernel, we create compatibility symlinks for /dev/ada devices, such as: /dev/ad8s1@ -> ada0s1 We don't do this for ATAPI CD-ROM devices. Any reason *not* to do this for ATAPI CD-ROM devices? i.e. /dev/cd0 -> acd0 It's a minor thing, but will definitely hit people who have /dev/acd0 in /etc/fstab when they upgrade to 9.0. People can read UPDATING and the release notes, but if we can do this minor thing, it might make migration easier. -- Craig Rodrigues rodr...@crodrigues.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
Michael Butler writes: > On 09/27/11 02:37, Daniel O'Connor wrote: > >> >> On 27/09/2011, at 13:33, Ade Lovett wrote: >>> That is to say, until 9.0-R happens, and for some considerable period >>> afterwards, ya'll can pretty much expect ports/ to be non-functional on >>> HEAD. PRs mentioning this will be gleefully closed referencing this >>> message. >> >> I imagine you can work around it by setting UNAME_r=9.0-CURRENT before >> building stuff. > > In some instances, this is insufficient. For multimedia/vlc, adding > "--host=i386-portbld-freebsd9" to "CONFIGURE_ARGS" in the Makefile is > required, multimedia/vlc builds just fine here on 10.0-CURRENT with UNAME_r. I guess you're using sudo(8) which *by default* doesn't preserve environment unlike su(1). Try using `env_keep', `!env_reset' or `-E' # stay away from /stable/9 as far as possible $ export UNAME_r='9.9-BLAH' $ sudo sh -c 'echo $UNAME_r' $ sudo -E sh -c 'echo $UNAME_r' 9.9-BLAH $ su root -c 'echo $UNAME_r' 9.9-BLAH ___ 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"
[CFT] hostap mode fixes with ath(4)
Hi all, I've just committed some hostap related ath(4) and ath_hal fixes to -HEAD. I've been testing these in my local 11n tree for the last few weeks and they've improved stability with all the 11n NICs but it has had the most impact when using the AR9220/AR9280 NICs. I'd appreciate it if I could get some third party verification here, especially if it has fixed things or broken things for you. I'd also like to hear if it has no impact. :-) I'd like to merge these back into 9.0 before -release occurs but I won't do it without enough testing. Thanks, 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: HEADS UP: ports/ and 10.0-CURRENT
On 09/27/11 02:37, Daniel O'Connor wrote: On 27/09/2011, at 13:33, Ade Lovett wrote: That is to say, until 9.0-R happens, and for some considerable period afterwards, ya'll can pretty much expect ports/ to be non-functional on HEAD. PRs mentioning this will be gleefully closed referencing this message. I imagine you can work around it by setting UNAME_r=9.0-CURRENT before building stuff. In some instances, this is insufficient. For multimedia/vlc, adding "--host=i386-portbld-freebsd9" to "CONFIGURE_ARGS" in the Makefile is required, imb ___ 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-BETA2 memstick USB image hangs my BIOS
On Sep 28, 2011 7:15 AM, "Matt Thyer" wrote: > > On Sep 28, 2011 4:11 AM, "Nathan Whitehorn" wrote: > > > > On 09/27/11 08:24, Matt Thyer wrote: > >> > >> On Sep 26, 2011 2:33 PM, "Adrian Chadd" wrote: > >>> > >>> > >>> On 26 September 2011 12:56, Kevin Oberman wrote: > >>> > I suspect that the thumb drive is the issue, not FreeBSD. > >>> > >>> > >>> I've booted the drive successfully on an older Via C3 board. > >>> > >>> I'm now watching it boot successfully on a Gigabyte GA-8I915PC Duo board. > >>> > >>> I'm going to try dumping a Linux distro on this USB disk after I get > >>> PCBSD 9.0-BETA2 installed. That way I can try to eliminate the USB > >>> disk as being "funny". > >>> (Although it's quite possible the USB disk is doing other funny things.) > >>> > >>> I really do think that this BIOS of mine dislikes a GPT partition > >>> inside an MBR/DOS setup. If this is the case, I wonder how many other > >>> motherboard/BIOSes have this problem. > >>> > >>> > >>> > >>> Adrian > >> > >> > >> I believe this would be due to the improper GPT partition table on the > >> FreeBSD memstick (as there is no backup partition table at the end of the > >> volume). > >> > >> This was discussed earlier and now that makefs has patches for UFS label > >> support there should be no need to continue to use GPT partitioning for the > >> memstick image. > >> > >> The background is that bsdinstall relys on labels (a good thing) and GPT > >> partition labels were being used but as there's no way to predict the size > >> of your memstick, the resulting GPT partition table was not valid (for > >> strict UEFI systems). > >> > >> The fix was to go back to traditional MS-DOS partitioning (MBR) but this > >> couldn't be done until makefs supported UFS labels. Someone came up with > >> patches so 9.0 should be able to have an MBR memstick and bsdinstall. > >> > >> I'm not sure how far this has progressed. > > > > > > I don't believe these patches were ever committed. Could you provide a pointer to them? > > -Nathan > > Yes, it was Andriy Gapon in this message: http://www.FreeBSD.org/cgi/mid.cgi?db=irt&id=4e60f480.6040...@freebsd.org That message id link doesn't seem to work. To find the message I searched for "makefs" on the FreeBSD mailing list archive search facility with only "Current" selected. The message was dated Fri, 2nd September 2011, 18:21:36 +0300 and the link to the patch was: http://people.freebsd.org/~avg/makefs.ffs-label.diff On Sep 28, 2011 7:15 AM, "Matt Thyer" wrote: > On Sep 28, 2011 4:11 AM, "Nathan Whitehorn" wrote: >> >> On 09/27/11 08:24, Matt Thyer wrote: >>> >>> On Sep 26, 2011 2:33 PM, "Adrian Chadd" wrote: On 26 September 2011 12:56, Kevin Oberman wrote: > I suspect that the thumb drive is the issue, not FreeBSD. I've booted the drive successfully on an older Via C3 board. I'm now watching it boot successfully on a Gigabyte GA-8I915PC Duo > board. I'm going to try dumping a Linux distro on this USB disk after I get PCBSD 9.0-BETA2 installed. That way I can try to eliminate the USB disk as being "funny". (Although it's quite possible the USB disk is doing other funny things.) I really do think that this BIOS of mine dislikes a GPT partition inside an MBR/DOS setup. If this is the case, I wonder how many other motherboard/BIOSes have this problem. Adrian >>> >>> >>> I believe this would be due to the improper GPT partition table on the >>> FreeBSD memstick (as there is no backup partition table at the end of the >>> volume). >>> >>> This was discussed earlier and now that makefs has patches for UFS label >>> support there should be no need to continue to use GPT partitioning for > the >>> memstick image. >>> >>> The background is that bsdinstall relys on labels (a good thing) and GPT >>> partition labels were being used but as there's no way to predict the > size >>> of your memstick, the resulting GPT partition table was not valid (for >>> strict UEFI systems). >>> >>> The fix was to go back to traditional MS-DOS partitioning (MBR) but this >>> couldn't be done until makefs supported UFS labels. Someone came up with >>> patches so 9.0 should be able to have an MBR memstick and bsdinstall. >>> >>> I'm not sure how far this has progressed. >> >> >> I don't believe these patches were ever committed. Could you provide a > pointer to them? >> -Nathan > > Yes, it was Andriy Gapon in this message: > http://www.FreeBSD.org/cgi/mid.cgi?db=irt&id=4e60f480.6040...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Experiences with FreeBSD 9.0-BETA2
Hi, On Tue, Sep 27, 2011 at 5:01 PM, Peter Jeremy wrote: > On 2011-Sep-26 19:48:23 -0400, Benjamin Kaduk wrote: >>On Mon, 26 Sep 2011, Arnaud Lacombe wrote: >>> The problem with /boot on a dedicated partition is the the kernel, >>> since at least 8.x, is installed by default with a vast majority of >>> crap. That's all the .symbols, that 99% of FreeBSD users will never >>> uses. >> >>My recollection is that this is because kensmith forgot to take >>'makeoptions DEBUG=-g' out of GENERIC when branching stable/8, and no one > > Not quite - 'DEBUG=-g' was a deliberate move to make it easier for > developers to talk users through faultfinding kernel issues. > > The correct fix is to install the .symbols files somewhere other than > /boot/kernel - unfortunately, no-one has developed the necessary > changes to the kernel installation. > I did too, will put patches online soon. - Arnaud > -- > Peter Jeremy > ___ 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-BETA 2, camcontrol readcap, no passthrough device found
On Tue, Sep 27, 2011 at 6:45 AM, Andriy Gapon wrote: > on 27/09/2011 02:02 Craig Rodrigues said the following: >> Is "camcontrol readcap" supposed to work for an ATA disk? > > Or, rephrased - is a SCSI command supposed to work for an ATA disk. > I am sure that you know the answer. > > P.S. camcontrol, of course, can be extended to support the corresponding ATA > command. Hi, According to this document: "SCSI / ATA Translation Standard" http://hackipedia.org/Hardware/SCSI/SCSI-ATA/SCSI%20%20ATA%20Translation.pdf The SCSI READ CAPACITY command should map to the ATA IDENTIFY DEVICE command. I am not familiar with the ATA_CAM code, so don't know if we do this properly for ATA_CAM. Maybe Alexander Motin can chime in. -- Craig Rodrigues rodr...@crodrigues.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-BETA2 memstick USB image hangs my BIOS
On Sep 28, 2011 4:11 AM, "Nathan Whitehorn" wrote: > > On 09/27/11 08:24, Matt Thyer wrote: >> >> On Sep 26, 2011 2:33 PM, "Adrian Chadd" wrote: >>> >>> >>> On 26 September 2011 12:56, Kevin Oberman wrote: >>> I suspect that the thumb drive is the issue, not FreeBSD. >>> >>> >>> I've booted the drive successfully on an older Via C3 board. >>> >>> I'm now watching it boot successfully on a Gigabyte GA-8I915PC Duo board. >>> >>> I'm going to try dumping a Linux distro on this USB disk after I get >>> PCBSD 9.0-BETA2 installed. That way I can try to eliminate the USB >>> disk as being "funny". >>> (Although it's quite possible the USB disk is doing other funny things.) >>> >>> I really do think that this BIOS of mine dislikes a GPT partition >>> inside an MBR/DOS setup. If this is the case, I wonder how many other >>> motherboard/BIOSes have this problem. >>> >>> >>> >>> Adrian >> >> >> I believe this would be due to the improper GPT partition table on the >> FreeBSD memstick (as there is no backup partition table at the end of the >> volume). >> >> This was discussed earlier and now that makefs has patches for UFS label >> support there should be no need to continue to use GPT partitioning for the >> memstick image. >> >> The background is that bsdinstall relys on labels (a good thing) and GPT >> partition labels were being used but as there's no way to predict the size >> of your memstick, the resulting GPT partition table was not valid (for >> strict UEFI systems). >> >> The fix was to go back to traditional MS-DOS partitioning (MBR) but this >> couldn't be done until makefs supported UFS labels. Someone came up with >> patches so 9.0 should be able to have an MBR memstick and bsdinstall. >> >> I'm not sure how far this has progressed. > > > I don't believe these patches were ever committed. Could you provide a pointer to them? > -Nathan Yes, it was Andriy Gapon in this message: http://www.FreeBSD.org/cgi/mid.cgi?db=irt&id=4e60f480.6040...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Experiences with FreeBSD 9.0-BETA2
On 09/27/2011 14:24, Peter Jeremy wrote: > On 2011-Sep-26 21:29:18 -0700, Kevin Oberman wrote: >> MBR allows 4 slices (which Windows and most of the world call >> partitions). Windows also >> allows the creation of "Extended Partitions, but FreeBSD does not >> support these. They result >> in device named with an 's' for slice. E.g. "da0s1". > > To be pedantic, the FreeBSD bootcode does not support _booting_ off > extended partitions. Once it is booted, FreeBSD has no problems > accessing them. Correct. > (I don't know if alternative bootcode such as grub > can boot FreeBSD within an extended partition). Well the installer won't even look there, so you'd have to do a fair bit of gymnastics to even get it there in the first place. And given the difficulty that grub sometimes has with booting it from primary partitions I wouldn't be hopeful, even if the FreeBSD late-stage boot loader could do it, which I highly doubt. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Experiences with FreeBSD 9.0-BETA2
On 2011-Sep-26 21:29:18 -0700, Kevin Oberman wrote: >MBR allows 4 slices (which Windows and most of the world call >partitions). Windows also >allows the creation of "Extended Partitions, but FreeBSD does not >support these. They result >in device named with an 's' for slice. E.g. "da0s1". To be pedantic, the FreeBSD bootcode does not support _booting_ off extended partitions. Once it is booted, FreeBSD has no problems accessing them. (I don't know if alternative bootcode such as grub can boot FreeBSD within an extended partition). Extended partitions show up as slice numbers 5 through 8 - eg da0s5 -- Peter Jeremy pgplCWAM1Tdn7.pgp Description: PGP signature
Re: Experiences with FreeBSD 9.0-BETA2
On 2011-Sep-26 19:48:23 -0400, Benjamin Kaduk wrote: >On Mon, 26 Sep 2011, Arnaud Lacombe wrote: >> The problem with /boot on a dedicated partition is the the kernel, >> since at least 8.x, is installed by default with a vast majority of >> crap. That's all the .symbols, that 99% of FreeBSD users will never >> uses. > >My recollection is that this is because kensmith forgot to take >'makeoptions DEBUG=-g' out of GENERIC when branching stable/8, and no one Not quite - 'DEBUG=-g' was a deliberate move to make it easier for developers to talk users through faultfinding kernel issues. The correct fix is to install the .symbols files somewhere other than /boot/kernel - unfortunately, no-one has developed the necessary changes to the kernel installation. -- Peter Jeremy pgpMT3DBqsHn5.pgp Description: PGP signature
Re: HEADS UP: ports/ and 10.0-CURRENT
Hi-- On Sep 27, 2011, at 11:50 AM, Gleb Kurtsou wrote: > It's more exciting than that. FreeBSD >= 10 is already seized by Apple :) > > http://www.google.com/codesearch#search/&q=__FreeBSD__%5CW%2B10&type=cs MacOS X doesn't define __FreeBSD__ either in CPP macros or the system headers: % touch foo.h; cpp -dM foo.h | grep __FreeBSD__ % cpp --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Regards, -- -Chuck ___ 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"
Passive FTP
I keep forgetting that fetch(1) defaults to active FTP, because login.conf(5) sets the FTP_PASSIVE_MODE environment variable, but every once in a while I try to "pkg_add -r" in single-user mode or using sudo(1) and it breaks. I have therefore flipped the switch and made passive FTP the default. Those who still want active FTP (what on earth for?) can set FTP_PASSIVE_MODE=NO in their environment. This overrides both the default setting and fetch(1)'s -p command-line option. I'd like to merge this to stable/9 before 9.0 ships, so I'd appreciate prompt feedback if anyone runs into any trouble. I currently do *not* plan to merge this to stable/8 or any older branches. 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"
Fatal trap 12: page fault while in kernel mode -- Stopped at atomic_subtract_int+0x4
I pretty reproducible get the following (handtranscribed) panic when sending an zfs snapshot to geli provider based on an USB stick that disappears (due to a bug, or because it's unplugged): Fatal trap 12: page fault while in kernel mode cpuid = 0: apic id = 00 fault virtual address = 0x288 fault code= supervisor write data, page not present instruction pointer = 0x20:0x808e2984 stack pointer = 0x28:0xff800023fba0 frame pointer = 0x28:0xff800023fbb0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 13 (g_up) [ thread pid 13 tid 100010 ] Stopped atatomic_subtract_int+0x4: lock subl %esi,(%rdi) db> where Tracing pid 13 tid 100010 td 0xfe00027998c0 atomic_subtract_int() at atomic_subtract_int+0x4 g_io_schdule_up() at g_io_schedule_up+0xa6 g_up_procbody() at g_up_procbody+0x5c fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff800023fd00, rbp 0 --- It seems to be important that ZFS is actually writing to the stick. If the stick is unplugged while the operation is stalled for other reasons, this particular panic doesn't seem to occur. While I end up in the debugger, dumping core doesn't work and produces a double fault and a bunch of duplicated messages (again handtranscribed): db> dump Dumping 443 out of 1974 MB: Dumping 443 out of 1974 MB Fatal double fault Fatal double fault rip = 0x8066a9e0 rip = 0x8066a9e0 rsp = 0xff800023c000 rsp = 0xff800023c000 rbp = 0xff800023c040 rbp = 0xff800023c040 cpuid = 0; cpuid = 0; apic id = 00 apic id = 00 panic: double fault panic: double fault cpuid = 0 cpuid = 0 KDB: stack backtrace: KDB: stack backtrace: db_trac_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 dblfault_handler() at dblfault_handler+0xa4 Xdblfault() at Xdblfault+0xa8 --- trap 0x17, rip = 0x8066a9e8, rsp = 0x80e56158, rbp = 0xff800023c040 --- mi_switch() at mi_switch+0x270 critical_exit() at critical_exit+0x9b spinlock_exit() at spinlock_exit+0x17 mi_switch() at mi_switch+0x275 critical_exit() at critical_exit+0x9b spinlock_exit() at spinlock_exit+0x17 [several pages of the previous three lines skipped] mi_switch() at mi_switch+0x275 critical_exit() at critical_exit+0x9b spinlock_exit() at spinlock_exit+0x17 intr_even_schedule_thread() at intr_event_schedule_thread+0xbb ahci_end_transaction() at ahci_end_transaction+0x398 ahci_ch_intr() at ahci_ch_intr+0x2b5 ahcipoll() at ahcipoll+0x15 xpt_polled_action() at xpt_polled_action+0xf7 I first noticed the problem with CURRENT from a week ago, but given that USB sticks don't usually disappear for me while sending snapshots to them, the problem might not be new. I'm using amd64, the panic above is from a custom kernel without WITNESS and INVARIANTS, but enabling them doesn't seem to affect the trace before the double fault. I wasn't able to reproduce the panic by unplugging the stick while writing to the pool using dd (but only tried once). Fabian signature.asc Description: PGP signature
Re: SCSI descriptor sense changes, testing needed
"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. Sep 27 20:39:24 r500 kernel: ahcich0: AHCI reset... Sep 27 20:39:24 r500 kernel: ahcich0: SATA connect time=900us status=0113 Sep 27 20:39:24 r500 kernel: ahcich0: AHCI reset: device found Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset... Sep 27 20:39:24 r500 kernel: ahcich1: SATA connect time=1000us status=0113 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device found Sep 27 20:39:24 r500 kernel: battery0: battery initialization start Sep 27 20:39:24 r500 kernel: ugen0.1: at usbus0 Sep 27 20:39:24 r500 kernel: uhub0: on usbus0 Sep 27 20:39:24 r500 kernel: ugen1.1: at usbus1 Sep 27 20:39:24 r500 kernel: uhub1: on usbus1 Sep 27 20:39:24 r500 kernel: ugen2.1: at usbus2 Sep 27 20:39:24 r500 kernel: uhub2: on usbus2 Sep 27 20:39:24 r500 kernel: ugen3.1: at usbus3 Sep 27 20:39:24 r500 kernel: uhub3: on usbus3 Sep 27 20:39:24 r500 kernel: ugen4.1: at usbus4 Sep 27 20:39:24 r500 kernel: uhub4: on usbus4 Sep 27 20:39:24 r500 kernel: ugen5.1: at usbus5 Sep 27 20:39:24 r500 kernel: uhub5: on usbus5 Sep 27 20:39:24 r500 kernel: ugen6.1: at usbus6 Sep 27 20:39:24 r500 kernel: uhub6: on usbus6 Sep 27 20:39:24 r500 kernel: ugen7.1: at usbus7 Sep 27 20:39:24 r500 kernel: uhub7: on usbus7 Sep 27 20:39:24 r500 kernel: acpi_acad0: acline initialization start Sep 27 20:39:24 r500 kernel: battery0: battery initialization done, tried 1 times Sep 27 20:39:24 r500 kernel: acpi_acad0: On Line Sep 27 20:39:24 r500 kernel: acpi_acad0: acline initialization done, tried 1 times Sep 27 20:39:24 r500 kernel: ahcich0: AHCI reset: device ready after 100ms Sep 27 20:39:24 r500 kernel: (aprobe0:ahcich0:0:0:0): SIGNATURE: Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 27 20:39:24 r500 kernel: ahci_end_transaction: got AHCI_ERR_INVALID! Sep 27 20:39:24 r500 kernel: ahci_end_transaction: op 12 dxfer_len 36 sense_len 18 sense_resid 0 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset... Sep 27 20:39:24 r500 kernel: ahcich1: SATA connect time=1000us status=0113 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device found Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 24 0 0 Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB request was invalid Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 27 20:39:24 r500 kernel: ahci_end_transaction: got AHCI_ERR_INVALID! Sep 27 20:39:24 r500 kernel: ahci_end_transaction: op 12 dxfer_len 36 sense_len 18 sense_resid 0 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset... Sep 27 20:39:24 r500 kernel: ahcich1: SATA connect time=1000us status=0113 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device found Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 24 0 0 Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB request was invalid Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device ready after 100ms Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): SIGNATURE: eb14 Sep 27 20:39:24 r500 kernel: ahci_end_transaction: got AHCI_ERR_INVALID! Sep 27 20:39:24 r500 kernel: ahci_end_transaction: op 12 dxfer_len 36 sense_len 18 sense_resid 0 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset... Sep 27 20:39:24 r500 kernel: ahcich1: SATA connect time=1000us status=0113 Sep 27 20:39:24 r500 kernel: ahcich1: AHCI reset: device found Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): INQUIRY. CDB: 12 0 0 24 0 0 Sep 27 20:39:24 r500 kernel: (aprobe1:ahcich1:0:0:0): CAM status: CCB request was invalid Sep 27 20:39:24 r500 kernel: uhub0: 2 ports with 2 removable, self powered Sep 27 20:39:24 r500 kernel: uhub1: 2 ports with 2 removable, self powered Sep 27 20:39:24 r50
Re: HEADS UP: ports/ and 10.0-CURRENT
On Sep 27, 2011, at 8:50 PM, Gleb Kurtsou wrote: > On (26/09/2011 23:03), Ade Lovett wrote: >> With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be >> expected, ports/ is going to be essentially unusable for a while. >> >> The issue stems from configure scripts (to choose something completely >> at random) assuming that FreeBSD would never jump to a double-digit >> major version number, and as such, various regexps for "freebsd1*" (ie: >> FreeBSD 1.1.x) are now matching "freebsd10". > > It's more exciting than that. FreeBSD >= 10 is already seized by > Apple :) > > http://www.google.com/codesearch#search/&q=__FreeBSD__%5CW%2B10&type=cs > That seems to be a FUSE-ism. __FreeBSD__ isn't defined anywhere on my OSX system.___ 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: HEADS UP: ports/ and 10.0-CURRENT
On (26/09/2011 23:03), Ade Lovett wrote: > With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be > expected, ports/ is going to be essentially unusable for a while. > > The issue stems from configure scripts (to choose something completely > at random) assuming that FreeBSD would never jump to a double-digit > major version number, and as such, various regexps for "freebsd1*" (ie: > FreeBSD 1.1.x) are now matching "freebsd10". It's more exciting than that. FreeBSD >= 10 is already seized by Apple :) http://www.google.com/codesearch#search/&q=__FreeBSD__%5CW%2B10&type=cs > > This is going to be some fairly fundamental breakage. > > However, until such time as 9.0-RELEASE is completely out of the door, > with autotools hat on, I will _not_ be committing any changes to > infrastructural ports to "fix" this. > > That is to say, until 9.0-R happens, and for some considerable period > afterwards, ya'll can pretty much expect ports/ to be non-functional on > HEAD. PRs mentioning this will be gleefully closed referencing this > message. > > -aDe > > Reply-To set to me. Please honor it. > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-BETA2 memstick USB image hangs my BIOS
On 09/27/11 08:24, Matt Thyer wrote: On Sep 26, 2011 2:33 PM, "Adrian Chadd" wrote: On 26 September 2011 12:56, Kevin Oberman wrote: I suspect that the thumb drive is the issue, not FreeBSD. I've booted the drive successfully on an older Via C3 board. I'm now watching it boot successfully on a Gigabyte GA-8I915PC Duo board. I'm going to try dumping a Linux distro on this USB disk after I get PCBSD 9.0-BETA2 installed. That way I can try to eliminate the USB disk as being "funny". (Although it's quite possible the USB disk is doing other funny things.) I really do think that this BIOS of mine dislikes a GPT partition inside an MBR/DOS setup. If this is the case, I wonder how many other motherboard/BIOSes have this problem. Adrian I believe this would be due to the improper GPT partition table on the FreeBSD memstick (as there is no backup partition table at the end of the volume). This was discussed earlier and now that makefs has patches for UFS label support there should be no need to continue to use GPT partitioning for the memstick image. The background is that bsdinstall relys on labels (a good thing) and GPT partition labels were being used but as there's no way to predict the size of your memstick, the resulting GPT partition table was not valid (for strict UEFI systems). The fix was to go back to traditional MS-DOS partitioning (MBR) but this couldn't be done until makefs supported UFS labels. Someone came up with patches so 9.0 should be able to have an MBR memstick and bsdinstall. I'm not sure how far this has progressed. I don't believe these patches were ever committed. Could you provide a pointer to them? -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
On Sep 27, 2011 10:04 AM, "Chris Rees" wrote: > > On 27 September 2011 10:18, Anton Shterenlikht wrote: > > On Tue, Sep 27, 2011 at 10:28:49AM +0200, O. Hartmann wrote: > >> On 09/27/11 08:35, h h wrote: > >> >Kevin Oberman writes: > >> > > >> >>On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett wrote: > >> >> > >> >>>With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be > >> >>>expected, ports/ is going to be essentially unusable for a while. > >> >>> > >> >>>The issue stems from configure scripts (to choose something completely > >> >>>at random) assuming that FreeBSD would never jump to a double-digit > >> >>>major version number, and as such, various regexps for "freebsd1*" (ie: > >> >>>FreeBSD 1.1.x) are now matching "freebsd10". > >> >[...] > >> >> > >> >>aDe, > >> >> > >> >>Could an entry to this effect be added to UPDATING (with a matching > >> >>entry when ports/ is "unbroken"). > >> > > >> >Also mention a workaround, e.g. > >> > > >> > $ export UNAME_r='9.9-BLAH' > >> > >> > >> Now I understand why some OS vendors have choosen the latin 10 'X' for > >> their tenth version of their operating system ... > > > > At least there will be a long rest after > > the move to 10 is complete.. until FreeBSD 100. > > > > > I'm afraid not; > > freebsd2*) > > We'll be just as screwed at 20. > > Hopefully we can fix that at the same time. > > Chris > Now is the moment we grab 'BSD', dropping the 'Free', and start fresh at a 1.x point... Rebrand and be more conservative with release numbering... Crazy right? Sorry for the noise... (Goes off to check the status of bsd.org) -Brandon ___ 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: ath / 802.11n performance issues and timer code
Adrian Chadd wrote:
> On 27 September 2011 23:56, Alexander Motin wrote:
>>> Yes it does. x86 does the same, but with more details. The general idea
>>> of the critical section is to block context switch out of idle thread
>>> until missed time events will be handled inside cpu_activeclock().
>> I was wrong. That's not good. I have no idea about mips wait instruction
>> semantics, related to disabling interrupts. In x86 semantics proper
>> solution is:
>
> [snip]
>
> Why is that you've protected the halt/wait part of the idle code
> inside a critical section?
>
> I'm not sure what to do about MIPS
Until proper solution found, try this patch. I think it should not harm:
--- machdep.c (revision 225796)
+++ machdep.c (working copy)
@@ -497,7 +497,8 @@
critical_enter();
cpu_idleclock();
}
- __asm __volatile ("wait");
+ if (!sched_runnable())
+ __asm __volatile ("wait");
if (!busy) {
cpu_activeclock();
critical_exit();
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Choosing between DELAY(useconds) and pause()
On Tue, Sep 27, 2011 at 10:39:44AM -0600, Julian Elischer wrote: > On 9/27/11 4:12 AM, Gavin Atkinson wrote: > >On Mon, 2011-09-26 at 09:30 -0400, John Baldwin wrote: > >>On Friday, September 23, 2011 11:21:06 am Gavin Atkinson wrote: > >>>On Thu, 2011-09-22 at 20:07 +0200, Hans Petter Selasky wrote: > On Thursday 22 September 2011 19:55:23 David Somayajulu wrote: > >It appears that the pause() function cannot be used in driver functions > >which are invoked early in the boot process. Is there is a kernel api > >which a device driver can use to determine whether to use pause() or > >DELAY(), for delays which are say greater than 10hz - may be even 1 hz > >? > Maybe you want to use something like this: > > if (cold) > DELAY() > else > pause() > > In your code. > >>>Note that this still shouldn't be done in your suspend/resume paths, as > >>>"cold" isn't set there, however there also appears to be no guarantee > >>>that pause() will ever return (as you could be running after the timer > >>>has been suspended, or before it resumes). > >>> > >>>I'm not sure what the correct answer is for suspend/resume code. > >>Hmmm, on x86 the timers are explicitly shutdown after the DEVICE_SUSPEND() > >>pass over the tree and re-enabled before DEVICE_RESUME(). Perhaps this > >>has > >>changed in HEAD though with the eventtimers stuff. I do think it is best > >>however, to use DELAY() in the suspend/resume path always regardless. > >I don't think head is any different from stable/8 in this respect - the > >same hack patch that fixes suspend/resume for me on head also fixes it > >on stable/8 (the patch basically fakes "cold" during USB > >suspend/resume). See my email to -usb a few months ago: > >http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1106041548370.26975 > > > >I'd really like some guidance as to the correct solution to this, I have > >four separate laptops which fail out of the box on 8 and 9, but > >suspend/resume perfectly with this hack. > > code for timers should have a generally readable state that says if > they are useable or not, and we should test that instead of 'cold' I think that this should be encapsulated into the usable function, instead of being directly exposed to the driver authors. With the my lack of imagination, I propose driver_delay() that would do if (cold) ... inside. pgp30errILlUx.pgp Description: PGP signature
Re: Choosing between DELAY(useconds) and pause()
On 9/27/11 4:12 AM, Gavin Atkinson wrote: On Mon, 2011-09-26 at 09:30 -0400, John Baldwin wrote: On Friday, September 23, 2011 11:21:06 am Gavin Atkinson wrote: On Thu, 2011-09-22 at 20:07 +0200, Hans Petter Selasky wrote: On Thursday 22 September 2011 19:55:23 David Somayajulu wrote: It appears that the pause() function cannot be used in driver functions which are invoked early in the boot process. Is there is a kernel api which a device driver can use to determine whether to use pause() or DELAY(), for delays which are say greater than 10hz - may be even 1 hz ? Maybe you want to use something like this: if (cold) DELAY() else pause() In your code. Note that this still shouldn't be done in your suspend/resume paths, as "cold" isn't set there, however there also appears to be no guarantee that pause() will ever return (as you could be running after the timer has been suspended, or before it resumes). I'm not sure what the correct answer is for suspend/resume code. Hmmm, on x86 the timers are explicitly shutdown after the DEVICE_SUSPEND() pass over the tree and re-enabled before DEVICE_RESUME(). Perhaps this has changed in HEAD though with the eventtimers stuff. I do think it is best however, to use DELAY() in the suspend/resume path always regardless. I don't think head is any different from stable/8 in this respect - the same hack patch that fixes suspend/resume for me on head also fixes it on stable/8 (the patch basically fakes "cold" during USB suspend/resume). See my email to -usb a few months ago: http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1106041548370.26975 I'd really like some guidance as to the correct solution to this, I have four separate laptops which fail out of the box on 8 and 9, but suspend/resume perfectly with this hack. code for timers should have a generally readable state that says if they are useable or not, and we should test that instead of 'cold' Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re[2]: Failure upgrading from 8-stable to current (9.0-Beta2)
Hi, Garrett.
No, that patch did not work.
because
+ tzsetup $${optC} -r; \
run current installed tzsetup which use libdialog.so
you must use just compiled one
/usr/obj/usr/src/usr.sbin/tzsetup/tzsetup
PS. I have 9-0Current 201101 upgrading to 9-0Beta2 20110925
I even try by hand setup ENV and manually run tzsetup from console
and got 'Undefined symbol "_nc_wacs"'
If I run '/usr/obj/usr/src/usr.sbin/tzsetup/tzsetup' from console it
works fine, so when I change Makefile as I noted below it works for me.
Вы писали 27 сентября 2011 г., 6:00:46:
GC> 2011/9/26 Коньков Евгений :
>> Hi
>>
>> For me patch do not working
>>
>> because tzsetup uses old tzsetup
>>
>> I use this:
>>
>>> --- share/zoneinfo/Makefile (revision 224989)
>>> +++ share/zoneinfo/Makefile (working copy)
>>> @@ -72,7 +72,8 @@
>>> optC="-C ${DESTDIR}"; \
>>> fi; \
>>> echo "Updating /etc/localtime"; \
>>> - tzsetup $${optC} -r; \
>>> + /usr/obj/usr/src/usr.sbin/tzsetup/tzsetup
>>> $${optC} -r; \
>>> fi; \
>>> else \
>>> echo "Run tzsetup(8) manually to update /etc/localtime."; \
>>>
>>
>> or run before world install
>> /usr/obj/usr/src/usr.sbin/tzsetup/tzsetup
>> I think it will be enough
GC> Or the patch attached to
GC> http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/160596 -- still open
GC> after 3 weeks...
GC> Thanks,
GC> -Garrett
--
С уважением,
Коньков mailto:kes-...@yandex.ru
___
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: ath / 802.11n performance issues and timer code
Adrian Chadd wrote: > On 27 September 2011 23:56, Alexander Motin wrote: >>> Yes it does. x86 does the same, but with more details. The general idea >>> of the critical section is to block context switch out of idle thread >>> until missed time events will be handled inside cpu_activeclock(). >> I was wrong. That's not good. I have no idea about mips wait instruction >> semantics, related to disabling interrupts. In x86 semantics proper >> solution is: > > [snip] > > Why is that you've protected the halt/wait part of the idle code > inside a critical section? As I've told before, critical section needed there to prevent context switch out of the idle thread before all missed during extended sleep timer events are handled and system time and other stuff are properly updated. > I'm not sure what to do about MIPS and as John said, it's likely that > each of the architectures has to be reviewed to make sure they're > doing the correct thing. x86 and ia64 do it properly, arm doesn't skip idle ticks, sparc64 doesn't have idle method at all. So problem seems mips specific. > Just as a note - having the NIC wait 90 * hz until the next scheduled > callout is .. sub-optimal. There's no way this is going to fly. > > In fact, having the NIC wait 1 * hz until the next scheduled tick > (with idletick=1) is also sub-optimal as it introduces artificial > latency spikes. And when I'm RX'ing 20,000 pps (and that's the low > rate for a NIC), 90ms with no interrupts is 1800 frames. An RX queue > that deep is just a bit ridiculous. Sure that's bad, but it should not happen. That's why there should be check for sched_runnable() before sleep. It should prevent system to enter sleep when it still has something to do. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath / 802.11n performance issues and timer code
On 27 September 2011 23:56, Alexander Motin wrote: >> Yes it does. x86 does the same, but with more details. The general idea >> of the critical section is to block context switch out of idle thread >> until missed time events will be handled inside cpu_activeclock(). > > I was wrong. That's not good. I have no idea about mips wait instruction > semantics, related to disabling interrupts. In x86 semantics proper > solution is: [snip] Why is that you've protected the halt/wait part of the idle code inside a critical section? I'm not sure what to do about MIPS and as John said, it's likely that each of the architectures has to be reviewed to make sure they're doing the correct thing. Just as a note - having the NIC wait 90 * hz until the next scheduled callout is .. sub-optimal. There's no way this is going to fly. In fact, having the NIC wait 1 * hz until the next scheduled tick (with idletick=1) is also sub-optimal as it introduces artificial latency spikes. And when I'm RX'ing 20,000 pps (and that's the low rate for a NIC), 90ms with no interrupts is 1800 frames. An RX queue that deep is just a bit ridiculous. 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: ath / 802.11n performance issues and timer code
Alexander Motin wrote:
> Adrian Chadd wrote:
>> .. erm, sys/mips/mips/machdep.c:
>>
>> /*
>> * call platform specific code to halt (until next interrupt) for the idle
>> loop
>> */
>> void
>> cpu_idle(int busy)
>> {
>> KASSERT((mips_rd_status() & MIPS_SR_INT_IE) != 0,
>> ("interrupts disabled in idle process."));
>> KASSERT((mips_rd_status() & MIPS_INT_MASK) != 0,
>> ("all interrupts masked in idle process."));
>>
>> if (!busy) {
>> critical_enter();
>> cpu_idleclock();
>> }
>> __asm __volatile ("wait");
>> if (!busy) {
>> cpu_activeclock();
>> critical_exit();
>> }
>> }
>>
>> .. does that look right?
>
> Yes it does. x86 does the same, but with more details. The general idea
> of the critical section is to block context switch out of idle thread
> until missed time events will be handled inside cpu_activeclock().
I was wrong. That's not good. I have no idea about mips wait instruction
semantics, related to disabling interrupts. In x86 semantics proper
solution is:
disable_intr();
if (sched_runnable())
enable_intr();
else
__asm __volatile("sti; hlt");
It makes interrupts enabled atomically with entering sleep state, that
closes race window and prevents entering into sleep after receiving
interrupt.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ath / 802.11n performance issues and timer code
Hi. Adrian Chadd wrote: > The AR71xx MIPS kernels didn't include PREEMPTION. This seems a bit > silly, as it's needed by sched_4bsd to actually compile in the code in > maybe_preempt(). > So I added it, and it simply increased CPU use without fixing the > issue. But yes, maybe_preempt() is now setting td_owepreempt. > > This however doesn't fix it. > > I have a gem of a trace here: > http://people.freebsd.org/~adrian/ath/ktr.7.sorted.txt . > > I've added some ath interrupt and RX tasklet trace points. Look for > RXEOL and work your way backwards. > > The course of events: > > * 2128: switch to idle > * 2130: ath0 intr comes in > * 2132/2133: put on runq, wakeup ath0 netisr > * 2134: maybe_preempt gets called, so hopefully td_owepreempt is going on > * 2136: "skip" in kern_clocksource.c > * 2139: the clock0 interrupt comes in - the latency between 2138 and > 2139 is huge (70ms?) Large delay there is not a problem. Eventtimer subsystem seen no active callouts for the next 79 HZ ticks. So it programs extended timer period. As I can see, it properly woken up withing 100us after scheduled time. > At this point it schedules clock0 swi, where 11 statclock entries get > recorded. Then it calls my ath netisr routine, but by this point RXEOL > (end of RX descriptor list) has occured. > > Now, there was an ath0 interrupt just before this. Is it possible that > two quick successive ath0 interrupts are triggering some strange > behaviour? Ah. I think I see the problem in mips cpu_idle() implementation. Your ath0 interrupt was scheduled after system started idle handling sequence and context switch was already blocked. In that case, directly before entering sleep, x86 system checks sched_runnable() status while keeping interrupts disabled to cancel sleep if there is any interrupts/processes are pending. Mips doesn't do it, so interrupt processing was delayed until the next timer tick. With idletick=1 problem probably also existed, but was less noticeable, because interrupt could only be delayed on one hz tick. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
On 27 September 2011 10:18, Anton Shterenlikht wrote: > On Tue, Sep 27, 2011 at 10:28:49AM +0200, O. Hartmann wrote: >> On 09/27/11 08:35, h h wrote: >> >Kevin Oberman writes: >> > >> >>On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett wrote: >> >> >> >>>With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be >> >>>expected, ports/ is going to be essentially unusable for a while. >> >>> >> >>>The issue stems from configure scripts (to choose something completely >> >>>at random) assuming that FreeBSD would never jump to a double-digit >> >>>major version number, and as such, various regexps for "freebsd1*" (ie: >> >>>FreeBSD 1.1.x) are now matching "freebsd10". >> >[...] >> >> >> >>aDe, >> >> >> >>Could an entry to this effect be added to UPDATING (with a matching >> >>entry when ports/ is "unbroken"). >> > >> >Also mention a workaround, e.g. >> > >> > $ export UNAME_r='9.9-BLAH' >> >> >> Now I understand why some OS vendors have choosen the latin 10 'X' for >> their tenth version of their operating system ... > > At least there will be a long rest after > the move to 10 is complete.. until FreeBSD 100. > I'm afraid not; freebsd2*) We'll be just as screwed at 20. Hopefully we can fix that at the same time. Chris ___ 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: ath / 802.11n performance issues and timer code
Adrian Chadd wrote:
> .. erm, sys/mips/mips/machdep.c:
>
> /*
> * call platform specific code to halt (until next interrupt) for the idle
> loop
> */
> void
> cpu_idle(int busy)
> {
> KASSERT((mips_rd_status() & MIPS_SR_INT_IE) != 0,
> ("interrupts disabled in idle process."));
> KASSERT((mips_rd_status() & MIPS_INT_MASK) != 0,
> ("all interrupts masked in idle process."));
>
> if (!busy) {
> critical_enter();
> cpu_idleclock();
> }
> __asm __volatile ("wait");
> if (!busy) {
> cpu_activeclock();
> critical_exit();
> }
> }
>
> .. does that look right?
Yes it does. x86 does the same, but with more details. The general idea
of the critical section is to block context switch out of idle thread
until missed time events will be handled inside cpu_activeclock().
Yes, this increases interrupt latency after long idle period. That's why
I have made it disabling under the high interrupt rate (busy flag set)
and written specially optimized hardclock() handler to be called only
once. Possibly same should be done to statclock() also.
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
On 09/27/11 16:27, Matthew D. Fuller wrote: > On Tue, Sep 27, 2011 at 09:36:17AM -0400 I heard the voice of > Robert Huff, and lo! it spake thus: >> Adrian Chadd writes: >>> Our children will be dealing with Y2038. :-) >> Statistically, some of us will. > Actually, I had to deal with it just last week... > > I was there, tomorrow. ___ 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: HEADS UP: ports/ and 10.0-CURRENT
On Tue, Sep 27, 2011 at 09:36:17AM -0400 I heard the voice of Robert Huff, and lo! it spake thus: > Adrian Chadd writes: > > Our children will be dealing with Y2038. :-) > > Statistically, some of us will. Actually, I had to deal with it just last week... -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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: ath / 802.11n performance issues and timer code
2011/9/27 John Baldwin :
> On Monday, September 26, 2011 11:36:26 pm Adrian Chadd wrote:
>> .. and as a follow up (and cc'ing attillo and freebsd-mips, in case
>> it's relevant to other platforms and there's a MIPS specific thing to
>> fix):
>>
>> * 2128: mi_switch to idle
>> * 2129: kern_clocksource.c:762 - ie, cpu_idleclock() has been called
>> * 2130: the ath interrupt comes in
>> * 2134: it's skipped for now as the idle thread is in a critical section
>> * 2136: kern_clocksource.c:266 - ie, getnextcpuevent(), inside
> cpu_idleclock().
>>
>> What I bet is happening is this race between the critical section +
>> cpu_idleclock() and the ath0 interrupt:
>>
>> * idle gets scheduled
>> * critical_enter() is called in the mips cpu_idle() routine
>> * the ath interrupt comes in here and gets handled, but since we're in
>> a critical section, it won't preempt things
>> * the cpu_idleclock() code completes without releasing the preemption,
>> and the only thing that wakes up from that wait is the next interrupt
>> (clock, arge0, etc.)
>
> I think this is a mips-specific bug, though it may be well to audit all the
> cpu_idle() implementations. On x86 the idle hooks all check sched_runnable()
> with interrupts disabled and then atomically re-enable interrupts and sleep
> only if that is false, e.g.:
>
> static void
> cpu_idle_hlt(int busy)
> {
> int *state;
>
> state = (int *)PCPU_PTR(monitorbuf);
> *state = STATE_SLEEPING;
> /*
> * We must absolutely guarentee that hlt is the next instruction
> * after sti or we introduce a timing window.
> */
> disable_intr();
> if (sched_runnable())
> enable_intr();
> else
> __asm __volatile("sti; hlt");
> *state = STATE_RUNNING;
> }
>
> I don't know if it is possible to do the same thing with the mips "wait"
> instruction.
After thinking about it I think this check is unnecessary.
sti, infact, doesn't enable interrupts before hlt (it just sets IF=1)
but interrupts can fire only after hlt, thus I don't think a
preemption or interrupts firing there can be possible.
This patch:
http://www.freebsd.org/~attilio/stihlt.patch
removes the check and also replaces simple 'hlt' instruction insertion
in C code with the already defined halt().
I still have to go through Adrian's e-mails so I'm not sure if the
logic you post is going to help him or not, but this is my thinking on
the x86 implementation (specifically).
Comments?
Attilio
--
Peace can only be achieved by understanding - A. Einstein
___
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: ath / 802.11n performance issues and timer code
On Monday, September 26, 2011 11:36:26 pm Adrian Chadd wrote:
> .. and as a follow up (and cc'ing attillo and freebsd-mips, in case
> it's relevant to other platforms and there's a MIPS specific thing to
> fix):
>
> * 2128: mi_switch to idle
> * 2129: kern_clocksource.c:762 - ie, cpu_idleclock() has been called
> * 2130: the ath interrupt comes in
> * 2134: it's skipped for now as the idle thread is in a critical section
> * 2136: kern_clocksource.c:266 - ie, getnextcpuevent(), inside
cpu_idleclock().
>
> What I bet is happening is this race between the critical section +
> cpu_idleclock() and the ath0 interrupt:
>
> * idle gets scheduled
> * critical_enter() is called in the mips cpu_idle() routine
> * the ath interrupt comes in here and gets handled, but since we're in
> a critical section, it won't preempt things
> * the cpu_idleclock() code completes without releasing the preemption,
> and the only thing that wakes up from that wait is the next interrupt
> (clock, arge0, etc.)
I think this is a mips-specific bug, though it may be well to audit all the
cpu_idle() implementations. On x86 the idle hooks all check sched_runnable()
with interrupts disabled and then atomically re-enable interrupts and sleep
only if that is false, e.g.:
static void
cpu_idle_hlt(int busy)
{
int *state;
state = (int *)PCPU_PTR(monitorbuf);
*state = STATE_SLEEPING;
/*
* We must absolutely guarentee that hlt is the next instruction
* after sti or we introduce a timing window.
*/
disable_intr();
if (sched_runnable())
enable_intr();
else
__asm __volatile("sti; hlt");
*state = STATE_RUNNING;
}
I don't know if it is possible to do the same thing with the mips "wait"
instruction.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-BETA 2, camcontrol readcap, no passthrough device found
on 27/09/2011 02:02 Craig Rodrigues said the following: > Is "camcontrol readcap" supposed to work for an ATA disk? Or, rephrased - is a SCSI command supposed to work for an ATA disk. I am sure that you know the answer. P.S. camcontrol, of course, can be extended to support the corresponding ATA command. -- Andriy Gapon ___ 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: HEADS UP: ports/ and 10.0-CURRENT
Adrian Chadd writes: > >> we can leave that to our grand children to figure out though 8) > > > > Wasn't that what people said about two-digit years? > > Our children will be dealing with Y2038. :-) Statistically, some of us will. Robert Huff ___ 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: HEADS UP: ports/ and 10.0-CURRENT
On 27 September 2011 13:57, Adrian Chadd wrote: > On 27 September 2011 20:22, Robert Huff wrote: > > > > krad writes: > >> we can leave that to our grand children to figure out though 8) > > > >Wasn't that what people said about two-digit years? > > Our children will be dealing with Y2038. :-) > > I'm sure some of us old-timers will be looking for high-paid 2038 consultancy work to fund our lavish retirement plans... ___ 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-BETA2 memstick USB image hangs my BIOS
On Sep 26, 2011 2:33 PM, "Adrian Chadd" wrote: > > On 26 September 2011 12:56, Kevin Oberman wrote: > > > I suspect that the thumb drive is the issue, not FreeBSD. > > I've booted the drive successfully on an older Via C3 board. > > I'm now watching it boot successfully on a Gigabyte GA-8I915PC Duo board. > > I'm going to try dumping a Linux distro on this USB disk after I get > PCBSD 9.0-BETA2 installed. That way I can try to eliminate the USB > disk as being "funny". > (Although it's quite possible the USB disk is doing other funny things.) > > I really do think that this BIOS of mine dislikes a GPT partition > inside an MBR/DOS setup. If this is the case, I wonder how many other > motherboard/BIOSes have this problem. > > > > Adrian I believe this would be due to the improper GPT partition table on the FreeBSD memstick (as there is no backup partition table at the end of the volume). This was discussed earlier and now that makefs has patches for UFS label support there should be no need to continue to use GPT partitioning for the memstick image. The background is that bsdinstall relys on labels (a good thing) and GPT partition labels were being used but as there's no way to predict the size of your memstick, the resulting GPT partition table was not valid (for strict UEFI systems). The fix was to go back to traditional MS-DOS partitioning (MBR) but this couldn't be done until makefs supported UFS labels. Someone came up with patches so 9.0 should be able to have an MBR memstick and bsdinstall. I'm not sure how far this has progressed. ___ 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: HEADS UP: ports/ and 10.0-CURRENT
On Tue, Sep 27, 2011 at 08:22:54AM -0400, Robert Huff wrote: > > krad writes: > > we can leave that to our grand children to figure out though 8) > > Wasn't that what people said about two-digit years? Not quite. There they mostly said "No way that this program will still be in use when two-digit years becomes a problem!" -- Erik Trulsson ertr1...@student.uu.se ___ 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: HEADS UP: ports/ and 10.0-CURRENT
2011/9/27 O. Hartmann : > Now I understand why some OS vendors have choosen the latin 10 'X' for their > tenth version of their operating system ... FreeBSD XP anyone? > ___ > freebsd-po...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > -- Eitan Adler ___ 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: HEADS UP: ports/ and 10.0-CURRENT
On 27 September 2011 20:22, Robert Huff wrote: > > krad writes: >> we can leave that to our grand children to figure out though 8) > > Wasn't that what people said about two-digit years? Our children will be dealing with Y2038. :-) 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: HEADS UP: ports/ and 10.0-CURRENT
krad writes: > we can leave that to our grand children to figure out though 8) Wasn't that what people said about two-digit years? Robert Huff ___ 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: [Solved] FreeBSD 9-Beta3 on X300 2 problems
On Tuesday 27 September 2011 13:53:41 Adrian Chadd wrote: > Hans, > > Why haven't those patches been committed? I don't know. There is no reason that they shouldn't, except I believe pause() should have the checks for cold and resuming/suspending instead of USB. Must have been forgotten :-) --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
Eduardo Morras writes:
> At 11:18 27/09/2011, Anton Shterenlikht wrote:
>
>> > Now I understand why some OS vendors have choosen the latin 10 'X' for
>> > their tenth version of their operating system ...
>>
>>At least there will be a long rest after
>>the move to 10 is complete.. until FreeBSD 100.
>
>
> Or move to hexadecimal
>
> $ export UNAME_r='A.0-CURRENT'
Wouldn't this fail if version is parsed with regex?
# from mysql
ELSEIF(CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
STRING(REGEX MATCH "[0-9]+\\.[0-9]+" VER "${CMAKE_SYSTEM_VERSION}")
SET(DEFAULT_PLATFORM "${CMAKE_SYSTEM_NAME}${VER}")
___
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: [Solved] FreeBSD 9-Beta3 on X300 2 problems
On Tue, 2011-09-27 at 19:53 +0800, Adrian Chadd wrote: > Hans, > > Why haven't those patches been committed? This patch is an absolute hack, and shouldn't be committed as it is. I would, however, appreciate some help in determining the correct solution. The solution may well involve not suspending/resuming hpet(4) or the other timers on the normal DEVICE_SUSPEND()/DEVICE_RESUME() path but instead doing them as the last thing to be suspended, or it may instead involve reworking the USB code (and potentially other code) to not need to sleep during suspend/resume. I don't know the right solution, but would really like to work with somebody who does. Please also see the thread "Choosing between DELAY(useconds) and pause()" on -current. Gavin ___ 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: HEADS UP: ports/ and 10.0-CURRENT
On 27 September 2011 10:18, Anton Shterenlikht wrote: > On Tue, Sep 27, 2011 at 10:28:49AM +0200, O. Hartmann wrote: > > On 09/27/11 08:35, h h wrote: > > >Kevin Oberman writes: > > > > > >>On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett wrote: > > >> > > >>>With the advent of the conversion of HEAD to 10.0-CURRENT and, as to > be > > >>>expected, ports/ is going to be essentially unusable for a while. > > >>> > > >>>The issue stems from configure scripts (to choose something completely > > >>>at random) assuming that FreeBSD would never jump to a double-digit > > >>>major version number, and as such, various regexps for "freebsd1*" > (ie: > > >>>FreeBSD 1.1.x) are now matching "freebsd10". > > >[...] > > >> > > >>aDe, > > >> > > >>Could an entry to this effect be added to UPDATING (with a matching > > >>entry when ports/ is "unbroken"). > > > > > >Also mention a workaround, e.g. > > > > > > $ export UNAME_r='9.9-BLAH' > > > > > > Now I understand why some OS vendors have choosen the latin 10 'X' for > > their tenth version of their operating system ... > > At least there will be a long rest after > the move to 10 is complete.. until FreeBSD 100. > > -- > Anton Shterenlikht > Room 2.6, Queen's Building > Mech Eng Dept > Bristol University > University Walk, Bristol BS8 1TR, UK > Tel: +44 (0)117 331 5944 > Fax: +44 (0)117 929 4423 > ___ > 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" > we can leave that to our grand children to figure out though 8) ___ 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: [Solved] FreeBSD 9-Beta3 on X300 2 problems
Hans, Why haven't those patches been committed? 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: outside the box (Re: HEADS UP: ports/ and 10.0-CURRENT)
On 09/27/11 16:46, per...@pluto.rain.com wrote: Ade Lovett wrote: The undeniable fact is that configure scripts in general have chosen to do things a certain way. Unfortunately for us (us being FreeBSD), we have now broken these conceptions by moving to a dual-digit major release. I don't suppose REVISION="A.1" i.e. using a single hex digit instead of two decimal digits, would work any better :) ... it will only postpone the agony ... better to deal now than shifting it to the future ... ___ 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: [Solved] FreeBSD 9-Beta3 on X300 2 problems
On Tue, 27 Sep 2011 08:21:23 +0800, Adrian Chadd wrote: Hi, Please try to do this without wlan loaded at all (not just down, but build your wifi support as a module.) Then try without X, see whether it's related to that or not. (And you haven't told us what your hardware is.) Gavin Atkinson send me this link : http://docs.freebsd.org/cgi/getmsg.cgi?fetch=96631+0+/usr/local/www/db/text/2011/freebsd-usb/20110605.freebsd-usb suspend / resume works like a charm with this pathes. Thanks all for help. Regards. 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-Beta3 on X300 problems.
I'm not sure why the machine panics when you unload uhci - if you can get any more information about the panic then please open a PR. As for the issue with suspend/resume hanging, can you please try the patch at http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1106041548370.26975 and see if that makes suspend/resume work? That patch is a hack rather than the correct solution, but it would be useful if you can test it and see if that makes any difference. Hello. Yours patch works! ;) Thanks a lot. Regards, Adrian. Thanks, Gavin ___ 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-Beta3 on X300 2 problems
Hi, Hello, thanks for reply. Please try to do this without wlan loaded at all (not just down, but build your wifi support as a module.) Then try without X, see whether it's related to that or not. First i make kldunload if_iwn. When i try to suspend from X, Xorg close, i see console and laptop suspend. When i resume it, i get console (any key dosent work), when i try to ALT+F9 i get black screen and beep;/ But when i try to suspen from console. I get : pci0: failed to set ACPI power state D2 \_SB_.PCI0_EXP0: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 \_SB_.PCI0_EXP1: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 \_SB_.PCI0_EXP2: AE_BAD_PARAMETER And laptop suspend, when i resume it. He hangs when i press any buttons it does nothing. And than i see on console that info : ugen0.2: ... disconnected ugen4.2: ... disconnected ubt0: at uhub0 ... disconnected then i see this presed lethers and acpi0: suspend request ignored (not ready yet) and laptops langs and beep ;/ (And you haven't told us what your hardware is.) #dmesg (+WITNESS) Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-BETA3 #3: Tue Sep 27 10:47:57 CEST 2011 cr4sh@x300:/sys/amd64/compile/GENERIC amd64 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM)2 Duo CPU L7100 @ 1.20GHz (1197.03-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbff BE> Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 2147483648 (2048 MB) avail memory = 2019139584 (1925 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110527/tbfadt-556) ACPI Warning: Optional field Gpe1Block has zero address or length: 0x102C/0x0 (20110527/tbfadt-586) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard CPU0: local APIC error 0x40 acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ef0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xfa00-0xfa0f,0xe000-0xefff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 7676k stolen memory vgapci1: mem 0xfa10-0xfa1f at device 2.1 on pci0 pci0: at device 3.0 (no driver attached) atapci0: port 0x1828-0x182f,0x180c-0x180f,0x1820-0x1827,0x1808-0x180b,0x1810-0x181f irq 18 at device 3.2 on pci0 ata2: on atapci0 ata3: on atapci0 pci0: at device 3.3 (no driver attached) em0: port 0x1840-0x185f mem 0xfa20-0xfa21,0xfa225000-0xfa225fff irq 20 at device 25.0 o n pci0 em0: Using an MSI interrupt acquiring duplicate lock of same type: "network driver" 1st &dev_spec->swflag_mutex @ dev/e1000/e1000_ich8lan.c:785 2nd &dev_spec->nvm_mutex @ dev/e1000/e1000_ich8lan.c:751 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x8de _mtx_lock_flags() at _mtx_lock_flags+0x79 e1000_acquire_nvm_ich8lan() at e1000_acquire_nvm_ich8lan+0x1e e1000_read_nvm_ich8lan() at e1000_read_nvm_ich8lan+0x76 e1000_post_phy_reset_ich8lan() at e1000_post_phy_reset_ich8lan+0x1b1 e1000_reset_hw_ich8lan() at e1000_reset_hw_ich8lan+0x4c1 em_attach() at em_attach+0x11bd device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a acpi_pci_attach() at acpi_pci_attach+0x14f device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a acpi_pcib_attach() at acpi_pcib_attach+0x1a7 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x231 device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a acpi_attach() at acpi_attach+0xbc5 device_attach() at device_attach+0x69 bus_generic_attach() at bus_generic_attach+0x1a nexus_acpi_attach() at nexus_acpi_attach+0x69 device_attach() at device_attach+0x69 bus_generic_new_pass() at bus_generic_new_pass+0xd6 bus_set_pass() at bus_set_pass+0
outside the box (Re: HEADS UP: ports/ and 10.0-CURRENT)
Ade Lovett wrote: > The undeniable fact is that configure scripts in general have > chosen to do things a certain way. Unfortunately for us (us > being FreeBSD), we have now broken these conceptions by moving > to a dual-digit major release. I don't suppose REVISION="A.1" i.e. using a single hex digit instead of two decimal digits, would work any better :) (IIRC alphas do sort after numerics, at least in the C locale.) ___ 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: HEADS UP: ports/ and 10.0-CURRENT
At 11:18 27/09/2011, Anton Shterenlikht wrote: > Now I understand why some OS vendors have choosen the latin 10 'X' for > their tenth version of their operating system ... At least there will be a long rest after the move to 10 is complete.. until FreeBSD 100. Or move to hexadecimal $ export UNAME_r='A.0-CURRENT' ___ 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: Choosing between DELAY(useconds) and pause()
On Mon, 2011-09-26 at 09:30 -0400, John Baldwin wrote: > On Friday, September 23, 2011 11:21:06 am Gavin Atkinson wrote: > > On Thu, 2011-09-22 at 20:07 +0200, Hans Petter Selasky wrote: > > > On Thursday 22 September 2011 19:55:23 David Somayajulu wrote: > > > > It appears that the pause() function cannot be used in driver functions > > > > which are invoked early in the boot process. Is there is a kernel api > > > > which a device driver can use to determine whether to use pause() or > > > > DELAY(), for delays which are say greater than 10hz - may be even 1 hz ? > > > > > > Maybe you want to use something like this: > > > > > > if (cold) > > > DELAY() > > > else > > > pause() > > > > > > In your code. > > > > Note that this still shouldn't be done in your suspend/resume paths, as > > "cold" isn't set there, however there also appears to be no guarantee > > that pause() will ever return (as you could be running after the timer > > has been suspended, or before it resumes). > > > > I'm not sure what the correct answer is for suspend/resume code. > > Hmmm, on x86 the timers are explicitly shutdown after the DEVICE_SUSPEND() > pass over the tree and re-enabled before DEVICE_RESUME(). Perhaps this has > changed in HEAD though with the eventtimers stuff. I do think it is best > however, to use DELAY() in the suspend/resume path always regardless. I don't think head is any different from stable/8 in this respect - the same hack patch that fixes suspend/resume for me on head also fixes it on stable/8 (the patch basically fakes "cold" during USB suspend/resume). See my email to -usb a few months ago: http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1106041548370.26975 I'd really like some guidance as to the correct solution to this, I have four separate laptops which fail out of the box on 8 and 9, but suspend/resume perfectly with this hack. Thanks, Gavin ___ 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-Beta3 on X300 problems.
On Mon, 2011-09-26 at 21:40 +0200, crsnet.pl wrote: > Hello. > I upgrade my FreeBSD 8.2-Release to FreeBSD 9-Beta and pkg_delete -f -a > and add new (that same) pkgs with pkg_add. > And system, xorgs, wine, opera, java, flash works ok, but... > I find two things that dont works ;/ > > 1. Suspend. > On FreeBSD 8.2 when i make ifconfig wlan0 down, and use zzz from X.org > all works. Suspend/resume. > Now when i make this same, system go to console and suspend. When i try > to resume. System show console, but when i try to press ALT+F9 i get > long beeep and system hang ;/ > I found on Google that i can try, to make uhci as a module, and first > unload it, and then suspend system. But when i try to kldload uhci > system go to dbg and hangs ;/ I'm not sure why the machine panics when you unload uhci - if you can get any more information about the panic then please open a PR. As for the issue with suspend/resume hanging, can you please try the patch at http://docs.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1106041548370.26975 and see if that makes suspend/resume work? That patch is a hack rather than the correct solution, but it would be useful if you can test it and see if that makes any difference. Thanks, Gavin ___ 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: Experiences with FreeBSD 9.0-BETA2
Holger Kipp writes: > Am 27.09.2011 um 10:48 schrieb Thomas Mueller: > >>> From Brett Glass : >> >>> Unfortunately, due to past history, /usr is mixed-use. It normally >>> contains both configuration information -- e.g. /usr/local/etc -- >>> and more volatile data such as users' home directories. This >>> prevents /usr/local/etc, which also contains mission-critical >>> configuration information, from being protected if you just protect >>> /. Some proprietary Unices have fixed this historical flaw in the >>> traditional hierarchy by moving /usr/local/etc to another location >>> and them symlinking it back to where seasoned administrators expect >>> it to be, thus honoring POLA. The three open source, old school >>> BSDs (Free, Net, Open) have not done this to date, but it's >>> something that should be considered in the long run. It would >>> certainly make the creation of embedded systems easier, as well as >>> enhancing security in multi-user systems! >> >> You mean users' home directories are under /usr/home rather than /home? >> >> I believe /home is more traditional, and decidedly my preference: >> good to put on a separate partition so it won't be touched by a >> system upgrade. > > Afaik /home has always been a symlink to /usr/home (unless you created a > separate /home-partition within FreeBSD). So it is up to the admin what > he chooses to do. Interesting, there is no mention of /home in hier(7). I guess it can be anything (without symlink) unlike, say, /compat stuff which needs at least symlink for `emulation tree' to work. ___ 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: HEADS UP: ports/ and 10.0-CURRENT
On Tue, Sep 27, 2011 at 10:28:49AM +0200, O. Hartmann wrote: > On 09/27/11 08:35, h h wrote: > >Kevin Oberman writes: > > > >>On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett wrote: > >> > >>>With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be > >>>expected, ports/ is going to be essentially unusable for a while. > >>> > >>>The issue stems from configure scripts (to choose something completely > >>>at random) assuming that FreeBSD would never jump to a double-digit > >>>major version number, and as such, various regexps for "freebsd1*" (ie: > >>>FreeBSD 1.1.x) are now matching "freebsd10". > >[...] > >> > >>aDe, > >> > >>Could an entry to this effect be added to UPDATING (with a matching > >>entry when ports/ is "unbroken"). > > > >Also mention a workaround, e.g. > > > > $ export UNAME_r='9.9-BLAH' > > > Now I understand why some OS vendors have choosen the latin 10 'X' for > their tenth version of their operating system ... At least there will be a long rest after the move to 10 is complete.. until FreeBSD 100. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ 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: Experiences with FreeBSD 9.0-BETA2
Am 27.09.2011 um 10:48 schrieb Thomas Mueller: >> From Brett Glass : > >> Unfortunately, due to past history, /usr is mixed-use. It normally >> contains both configuration information -- e.g. /usr/local/etc -- >> and more volatile data such as users' home directories. This >> prevents /usr/local/etc, which also contains mission-critical >> configuration information, from being protected if you just protect >> /. Some proprietary Unices have fixed this historical flaw in the >> traditional hierarchy by moving /usr/local/etc to another location >> and them symlinking it back to where seasoned administrators expect >> it to be, thus honoring POLA. The three open source, old school >> BSDs (Free, Net, Open) have not done this to date, but it's >> something that should be considered in the long run. It would >> certainly make the creation of embedded systems easier, as well as >> enhancing security in multi-user systems! > > You mean users' home directories are under /usr/home rather than /home? > > I believe /home is more traditional, and decidedly my preference: good to put > on a separate partition so it won't be touched by a system upgrade. Afaik /home has always been a symlink to /usr/home (unless you created a separate /home-partition within FreeBSD). So it is up to the admin what he chooses to do. Best regards, Holger -- Holger Kipp Diplom-Mathematiker Senior Consultant Tel. : +49 30 436 58 114 Fax. : +49 30 436 58 214 Mobil: +49 178 36 58 114 Email: holger.k...@alogis.com alogis AG Alt-Moabit 90b D-10559 Berlin web : http://www.alogis.com -- alogis AG Sitz/Registergericht: Berlin/AG Charlottenburg, HRB 71484 Vorstand: Arne Friedrichs, Joern Samuelson Aufsichtsratsvorsitzender: Reinhard Mielke ___ 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-BETA2 or 3?
On Tue, 27 Sep 2011 09:06:53 + (GMT), Thomas Mueller wrote: I see a thread, "FreeBSD 9-Beta3 on X300 problems." and now am curious about what is the current beta? I looked at ftp://ftp.freebsd.org/pub/FreeBSD/releases/ and found a BETA3 but only for some platforms not including i386 and amd64. Maybe the burncd problem, not working on SATA, is a temporary barrier? Not to sound impatient, I'd rather wait for something good than something released prematurely. BETA3 is uploaded to all mirrors ATM, so expect an announcement about its availability, soon. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD 9.0-BETA2 or 3?
I see a thread, "FreeBSD 9-Beta3 on X300 problems." and now am curious about what is the current beta? I looked at ftp://ftp.freebsd.org/pub/FreeBSD/releases/ and found a BETA3 but only for some platforms not including i386 and amd64. Maybe the burncd problem, not working on SATA, is a temporary barrier? Not to sound impatient, I'd rather wait for something good than something released prematurely. Tom ___ 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: Experiences with FreeBSD 9.0-BETA2
>From Brett Glass : > Unfortunately, due to past history, /usr is mixed-use. It normally > contains both configuration information -- e.g. /usr/local/etc -- > and more volatile data such as users' home directories. This > prevents /usr/local/etc, which also contains mission-critical > configuration information, from being protected if you just protect > /. Some proprietary Unices have fixed this historical flaw in the > traditional hierarchy by moving /usr/local/etc to another location > and them symlinking it back to where seasoned administrators expect > it to be, thus honoring POLA. The three open source, old school > BSDs (Free, Net, Open) have not done this to date, but it's > something that should be considered in the long run. It would > certainly make the creation of embedded systems easier, as well as > enhancing security in multi-user systems! You mean users' home directories are under /usr/home rather than /home? I believe /home is more traditional, and decidedly my preference: good to put on a separate partition so it won't be touched by a system upgrade. Tom ___ 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: HEADS UP: ports/ and 10.0-CURRENT
On 09/27/11 08:35, h h wrote: Kevin Oberman writes: On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett wrote: With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be expected, ports/ is going to be essentially unusable for a while. The issue stems from configure scripts (to choose something completely at random) assuming that FreeBSD would never jump to a double-digit major version number, and as such, various regexps for "freebsd1*" (ie: FreeBSD 1.1.x) are now matching "freebsd10". [...] aDe, Could an entry to this effect be added to UPDATING (with a matching entry when ports/ is "unbroken"). Also mention a workaround, e.g. $ export UNAME_r='9.9-BLAH' Now I understand why some OS vendors have choosen the latin 10 'X' for their tenth version of their operating system ... ___ 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: HEADS UP: ports/ and 10.0-CURRENT
On Tue, 27 Sep 2011, h h wrote: Kevin Oberman writes: On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett wrote: With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be expected, ports/ is going to be essentially unusable for a while. The issue stems from configure scripts (to choose something completely at random) assuming that FreeBSD would never jump to a double-digit major version number, and as such, various regexps for "freebsd1*" (ie: FreeBSD 1.1.x) are now matching "freebsd10". [...] aDe, Could an entry to this effect be added to UPDATING (with a matching entry when ports/ is "unbroken"). Also mention a workaround, e.g. $ export UNAME_r='9.9-BLAH' Assuming that a script's detection algorithm is simple. Please see http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2007-07/msg00597.html for a more complete masquerading algorithm.p -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: 9.0 beta2 & the new bsdinstaller
On Sun, Sep 25, 2011 at 3:01 PM, Fbsd8 wrote: > deeptec...@gmail.com wrote: >> >> Fbsd8 wrote: >>> >>> 6. At the "Complete screen" when the reboot option is selected the >>> cd/dvd drive should automatically open so the install media can be >>> removed just like sysinstall does. If disc1.iso or dvd.iso was installed >>> to memstick and used to boot from to install the system, then a message >>> screen should pop out saying the memstick has to be removed now before >>> the reboot starts. Don't let the reboot occur until the memstick is >>> removed. >> >> Do NOT alter! More often than not, >> (1) you keep floppies, optical discs, and memory sticks in your >> computer without intending to boot from them, and >> (2) you'll want to use your BIOS's boot-once functionality (press a >> specific keyboard button to bring up the media choser menu for that >> boot; otherwise boot from the hard drives) whenever you do want to >> boot from floppies, optical discs, or memory sticks. >> >> >> > You have missed the subject completely of what #6 is addressing. This has > nothing to do with telling the pc hardware which media to boot from at power > up time like you suggest in your post. > > This has to do with the logic of the new bsdinstall process and the > differences between bsdinstall and sysinstall in the way the install media > is removed from the pc before it reboots as part of the normal install > process. I did not suggest anything related to hardware settings. FreeBSD can't and shouldn't manipulate settings of a proprietary BIOS. In fact, proper BIOSes have the option to allow changes to settings only via the hardware-based BIOS menu (ie., to block the OS from changing BIOS settings). Instead, I stated the reason why - unmounting and ejecting the disc, or - unmounting the memory stick and waiting for it to be removed will be a nuisance for the majority of the users, and a convenience for only the minority. As others (Chris Rees, Miroslav Lachman) have said, a simple reminder is sufficient. BTW, let's assume that the user uses WRONG(TM) boot settings in the BIOS, and therefore does want to remove a disc or memory stick at the end of the installation process. What is the manual removability of discs and memory sticks at the end of the installation process? Because - I can't eject discs (via the drive's eject button) while they are mounted, - recently, there were some FreeBSD instability issues when unplugging mounted memory sticks. So it seems that bsdinstall should first unmount the installation media. On the other hand, unacknowledged unmounting is still not desired, because theoretically the user might want to do something via the auxiliary console, for which the installation media is required. To cover the above points, I propose the following dialog: (1) the body text of "Installation has finished. You may now reboot the machine. You also have the option to unmount/eject the installation media before rebooting. Removal of the media may be required to avoid starting the installer again on the next boot.", (2) a button labeled "unmount/eject installation media", (3) a button labeled "reboot", which should be the default selection. Chosing the "unmount/eject installation media" button will unmount the media, and eject it if it's a disc, and the following dialog will be shown: (1) the body text of "Please remove the installation media. Press any key to reboot." ___ 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: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, Sep 26, 2011 at 9:23 PM, Adrian Chadd wrote:
> .. and if someone would like to contribute patches to burncd to update
> it, I think there'd be at least one committer here who would be happy
> to help you get your changes into the tree.
>
> :-)
Hi,
I think we need something like the following patch.
--
Craig Rodrigues
rodr...@crodrigues.org
Index: sbin/atacontrol/atacontrol.c
===
--- sbin/atacontrol/atacontrol.c(revision 225368)
+++ sbin/atacontrol/atacontrol.c(working copy)
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -377,7 +378,19 @@
main(int argc, char **argv)
{
int fd, mode, channel, array;
+ int ata_cam;
+ size_t ata_cam_len = sizeof(int);
+ if (sysctlbyname("hw.ata.ata_cam_enabled", &ata_cam, &ata_cam_len,
+ NULL, 0) < 0) {
+ ata_cam = 0;
+ }
+
+ if (ata_cam == 1) {
+ errx(1, "ATA_CAM option is enabled in kernel.\n"
+ "Please use camcontrol instead.\n");
+ }
+
if (argc < 2)
usage();
Index: sbin/atacontrol/atacontrol.8
===
--- sbin/atacontrol/atacontrol.8(revision 225368)
+++ sbin/atacontrol/atacontrol.8(working copy)
@@ -25,12 +25,19 @@
.\"
.\" $FreeBSD$
.\"
-.Dd February 21, 2009
+.Dd September 27, 2011
.Dt ATACONTROL 8
.Os
.Sh NAME
.Nm atacontrol
.Nd ATA device driver control program
+.Pp
+This utility was
+.Em deprecated
+in
+.Fx 9.0 .
+See
+.Sx NOTES .
.Sh SYNOPSIS
.Nm
.Aq Ar command
@@ -361,11 +368,17 @@
up all the time.
.Sh SEE ALSO
.Xr ata 4
+.Xr cam 4
+.Xr camcontrol 8
.Sh HISTORY
The
.Nm
utility first appeared in
.Fx 4.6 .
+.Pp
+.Nm
+was deprecated in
+.Fx 9.0 .
.Sh AUTHORS
.An -nosplit
The
@@ -377,3 +390,16 @@
This manual page was written by
.An S\(/oren Schmidt
.Aq s...@freebsd.org .
+.Sh NOTES
+The
+.Nm
+utility was deprecated in
+.Fx 9.0 .
+When
+.Bd -ragged -offset indent
+.Cd "options ATA_CAM"
+.Ed
+.Pp
+is compiled into the kernel, then
+.Xr camcontrol 8
+must be used instead.
Index: usr.sbin/burncd/burncd.8
===
--- usr.sbin/burncd/burncd.8(revision 225368)
+++ usr.sbin/burncd/burncd.8(working copy)
@@ -33,6 +33,13 @@
.Sh NAME
.Nm burncd
.Nd control the ATAPI CD-R/RW driver
+.Pp
+This utility was
+.Em deprecated
+in
+.Fx 9.0 .
+See
+.Sx NOTES .
.Sh SYNOPSIS
.Nm
.Op Fl deFlmnpqtv
@@ -211,6 +218,10 @@
.Nm
utility appeared in
.Fx 4.0 .
+.Pp
+.Nm
+was deprecated in
+.Fx 9.0 .
.Sh AUTHORS
The
.Nm
@@ -220,3 +231,19 @@
.Aq s...@freebsd.org .
.Sh BUGS
Probably, please report when found.
+.Sh NOTES
+When
+.Bd -ragged -offset indent
+.Cd "options ATA_CAM"
+.Ed
+.Pp
+is compiled into the kernel, then
+.Xr cdrecord 1 ,
+available in the
+.Fx
+Ports Collection as part of the
+.Pa sysutils/cdrtools
+port, must be used instead.
+Refer to:
+.Pp
+http://www.freebsd.org/doc/handbook/creating-cds.html#CDRECORD
Index: usr.sbin/burncd/burncd.c
===
--- usr.sbin/burncd/burncd.c(revision 225368)
+++ usr.sbin/burncd/burncd.c(working copy)
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include
#define BLOCKS 16
@@ -80,8 +81,24 @@
int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0;
int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
+ int ata_cam;
+ size_t ata_cam_len = sizeof(int);
const char *dev, *env_speed;
+ if (sysctlbyname("hw.ata.ata_cam_enabled", &ata_cam, &ata_cam_len,
+ NULL, 0) < 0) {
+ ata_cam = 0;
+ }
+
+ if (ata_cam == 1) {
+ printf("\nATA_CAM option is enabled in kernel.\n"
+ "Install the sysutils/cdrtools port and use cdrecord "
+ "instead.\n\n"
+ "Please refer to:\n"
+
"http://www.freebsd.org/doc/handbook/creating-cds.html#CDRECORD\n";);
+ exit(1);
+ }
+
if ((dev = getenv("CDROM")) == NULL)
dev = "/dev/acd0";
Index: sys/dev/ata/ata-all.c
===
--- sys/dev/ata/ata-all.c (revision 225368)
+++ sys/dev/ata/ata-all.c (working copy)
@@ -101,6 +101,9 @@
/* local vars */
static int ata_dma = 1;
static int atapi_dma = 1;
+#ifdef ATA_CAM
+static int ata_cam_enabled = 1;
+#endif
/* sysctl vars */
SYSCTL_NODE(_hw, OID_AUTO, ata, CTLFLAG_RD, 0, "ATA driver parameters");
@@ -120,6 +123,11 @@
TUNABLE_INT("hw.ata.setmax", &ata_setmax);
SYSCTL_INT(_hw_ata, OID_AUTO, setmax, CTLFLAG_RDTUN, &ata_setmax, 0,
"ATA disk set max native address");
+#ifdef ATA_CAM
+SYSCTL_INT(_hw_ata, OID_AUTO, a
Re: bin/160979: 9.0 burncd error caused by change to cd0 from acd0
On Mon, Sep 26, 2011 at 9:10 PM, Garrett Cooper wrote: > > Noting something in the documentation is fine. The point is that there's a > lot of wasted electrons being tossed about about a fairly trivial issue: > most of the apps that burn/use CDs were converted over to some logic long > ago that matches cdrecord. The only apps that haven't really been > (atacontrol, burncd) were abandoned because the developer isn't an active > maintainer. Actually, the electrons are not wasted. Fbsd8 raised some legitimate issues that average users are going to hit and complain about. I think it is worth taking some extra time to fix the man pages, *and* add useful error messages to the utilities. You raised some valid points that burncd and atacontrol are affected utilities. There may be some other utilities or 3rd party ports that may be affected that we haven't thought about yet. I am not sure if cdcontrol(1) will be affected, but it looks like that works with CAM and the old ATA subsystem, so it may be OK. I took a second look at your patch to burncd, and I don't think it is a good enough fix. I am working on a patch now, which I will submit soon. -- Craig Rodrigues rodr...@crodrigues.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: ports/ and 10.0-CURRENT
Kevin Oberman writes: > On Mon, Sep 26, 2011 at 9:03 PM, Ade Lovett wrote: > >> With the advent of the conversion of HEAD to 10.0-CURRENT and, as to be >> expected, ports/ is going to be essentially unusable for a while. >> >> The issue stems from configure scripts (to choose something completely >> at random) assuming that FreeBSD would never jump to a double-digit >> major version number, and as such, various regexps for "freebsd1*" (ie: >> FreeBSD 1.1.x) are now matching "freebsd10". [...] > > aDe, > > Could an entry to this effect be added to UPDATING (with a matching > entry when ports/ is "unbroken"). Also mention a workaround, e.g. $ export UNAME_r='9.9-BLAH' ___ 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: HEADS UP: ports/ and 10.0-CURRENT
On 27/09/2011, at 13:33, Ade Lovett wrote: > That is to say, until 9.0-R happens, and for some considerable period > afterwards, ya'll can pretty much expect ports/ to be non-functional on > HEAD. PRs mentioning this will be gleefully closed referencing this > message. I imagine you can work around it by setting UNAME_r=9.0-CURRENT before building stuff. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
