SeaMonkey eats the CPU as of r232144

2012-02-29 Thread deeptec...@gmail.com
As of r232144, SeaMonkey (a web browser) runs rather slowly and is
constantly eating 100% CPU time. Before r232144, SeaMonkey would start
up and run faster, and when it is not in use (is idling), its CPU
usage would slowly converge to 0.

I have a P4 processor [with HT], an r232012 world, and similarly recent ports.
___
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


rm -rf / fanclub

2012-02-23 Thread deeptec...@gmail.com
Well, I did not actually get a full membership to the rm -rf /
fanclub, but I managed to remove all installed ports, basically
requiring a full reinstall. Here's how it happened:

Once upon a time, I did a full reinstall (not because of rm -rf
/-like things). I kept the old installation's full filesystem
hierarchy located in /old. I was then going through the old hierarchy
to salvage important bits and delete the rest. At one point, I was in
/old/usr, and did rm -rf X11R6/ bin/ lib/  I was a bit hasty,
and forgot to remove the ending backslashes from the directory names,
which were inserted by csh's autocompletion. And as it turns out,
X11R6 is actually a symlink to /usr/local, and not usr/local or
.usr/local! Also, /home is a symlink to /usr/home, and not usr/home or
./usr/home, but I managed to stay clear of that deathtrap.

In a web search, I found that someone was about to fix the /home
symlink in 2004 [1]. Uhm, any time soon?

BTW, is the existence of the X11R6 symlink still required for some
compatibility?

[1] http://lists.freebsd.org/pipermail/freebsd-hackers/2004-January/005391.html
___
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: rm -rf / fanclub

2012-02-23 Thread deeptec...@gmail.com
On Thu, Feb 23, 2012 at 11:41 PM, deeptec...@gmail.com
deeptec...@gmail.com wrote:
 X11R6 is actually a symlink to /usr/local, and not usr/local or
 .usr/local! Also, /home is a symlink to /usr/home, and not usr/home or
 ./usr/home

I meant to say that X11R6 should be a symlink to local or ./local.
About /home: I've just noticed that /home points to usr/home in the
newest release. The newest basic installation (base + kernel) doesn't
even come with an X11R6 symlink, yet I did have it after a full
install (-CURRENTization + ports), so that symlink must be coming from
mergemaster or some port.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


WTF mergemaster VCS Id checking?

2012-01-15 Thread deeptec...@gmail.com
Every time I run mergemaster, I have to manually confirm all of the
local changes I have done to /etc (ie., state how to merge the
temporary and existing files), even files have not changed in the
upstream since the last mergemaster run (for example,
temproot/etc/master.passwd virtually never changes). This behaviour is
annoying, but I've already gotten used to it, and thought that it's
the preferred one, to force a system administrator to review,
periodically, all changes in /etc.

I was surprized that today, mergemaster did not mention one of my
changes in /etc:
*** Temp ./etc/rc.d/bgfsck and installed have the same CVS Id, deleting

So it now seems that it actually is intended for mergemaster to
mention only files that have changed in the upstream since the last
mergemaster run, but that funtionality fails. Apparently, some
upstream files have the following VCS Id:
# $FreeBSD$
and that anulls version checking. Recently, a lot of files in /etc
(ie., rc.d files) have received full VCS Id strings, but not all.
Someone ought to touch files in the subversion repository?

So in either way you look at it, something is WRONG(TM).

BTW, off-topic:
1. mergemaster outputs CVS Id, while mergemaster's manpage contains
VCS Id. One of these is WRONG(TM). Which one?
2. mergemaster outputs Use 'i' to install merged file. TODO: add a the.
3. The BUGS section of mergemaster's manpage is redundant.
___
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: lockup during probing because of a memory stick

2011-10-30 Thread deeptec...@gmail.com
On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky hsela...@c2i.net wrote:

 On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote:

 I don't recall this case happening some time ago. But now, this

 happens with and without the NEW_PCIB option. I mention this because

 ``acpi0: A M I OEMXSDT on motherboard'' is shortly followed by

 ``acpi0: reservation of 0, a (3) failed'', whatever that means.



 ACPI involves some USB BIOS code most likely which is causing the crash. I

 think this is maybe not a FreeBSD issue, but if you can binary search the

 revisions to find exactly what commit broke your system, them I can look

 further at your issue.



Actually, I've just tested a pre-compiled 7.3-RELEASE GENERIC kernel,
and the lockup also occurs there.



 Have you tried to turn off USB legacy support in the BIOS?



Hmm. Interesting, only a combination of the following result in the lockup:

- Legacy USB Support: Auto (enable if and only if a USB device is
connected) or Enabled,

- USB 2.0 Controller: Enabled,

- USB 2.0 Controller Mode: HiSpeed,

- the memory stick is plugged in when the computer starts, and

- the memory stick is plugged in when FreeBSD boots.

Note that, to reproduce the lockup, it is not sufficient to just have
the said BIOS settings (Legacy USB Support: Enabled, etc.), it is also
required that the mutherboard recognize the memory stick when the
computer starts, and to have the memory stick connected when FreeBSD
boots. (If I disable 2.0 support, or set the speed to FullSpeed, or
disable legacy support, or do not have the stick plugged in when the
computer starts, or do not have the stick plugged in when FreeBSD
boots, then the lockup does not occur.)



But Windows XP does not produce any lockups in the case where FreeBSD
does. Furthermore, in all cases, the memory stick is usable from
FreeBSD if FreeBSD boots successfully. So why should I expect FreeBSD
to lock up?
___
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: lockup during probing because of a memory stick

2011-10-30 Thread deeptec...@gmail.com
On Mon, Oct 31, 2011 at 3:01 AM, Garrett Cooper yaneg...@gmail.com wrote:
 On Oct 30, 2011, at 6:47 PM, deeptec...@gmail.com wrote:

 On Sun, Oct 30, 2011 at 9:27 PM, Hans Petter Selasky hsela...@c2i.net 
 wrote:

 On Saturday 29 October 2011 23:26:29 deeptec...@gmail.com wrote:

 I don't recall this case happening some time ago. But now, this

 happens with and without the NEW_PCIB option. I mention this because

 ``acpi0: A M I OEMXSDT on motherboard'' is shortly followed by

 ``acpi0: reservation of 0, a (3) failed'', whatever that means.



 ACPI involves some USB BIOS code most likely which is causing the crash. I

 think this is maybe not a FreeBSD issue, but if you can binary search the

 revisions to find exactly what commit broke your system, them I can look

 further at your issue.



 Actually, I've just tested a pre-compiled 7.3-RELEASE GENERIC kernel,
 and the lockup also occurs there.



 Have you tried to turn off USB legacy support in the BIOS?



 Hmm. Interesting, only a combination of the following result in the lockup:

 - Legacy USB Support: Auto (enable if and only if a USB device is
 connected) or Enabled,

 - USB 2.0 Controller: Enabled,

 - USB 2.0 Controller Mode: HiSpeed,

 - the memory stick is plugged in when the computer starts, and

 - the memory stick is plugged in when FreeBSD boots.

 Note that, to reproduce the lockup, it is not sufficient to just have
 the said BIOS settings (Legacy USB Support: Enabled, etc.), it is also
 required that the mutherboard recognize the memory stick when the
 computer starts, and to have the memory stick connected when FreeBSD
 boots. (If I disable 2.0 support, or set the speed to FullSpeed, or
 disable legacy support, or do not have the stick plugged in when the
 computer starts, or do not have the stick plugged in when FreeBSD
 boots, then the lockup does not occur.)



 But Windows XP does not produce any lockups in the case where FreeBSD
 does. Furthermore, in all cases, the memory stick is usable from
 FreeBSD if FreeBSD boots successfully. So why should I expect FreeBSD
 to lock up?


        Vendor hacks and limited testing on other OSes is the most likely 
 cause, if it's not a bug within FreeBSD. Just to narrow things down a bit...
 1. Are there are BIOS updates for your motherboard?

Yes, and I have the latest non-beta version (v1019 (dated 2004-11-08)
for P4P800 mutherboards).

 2. Do you have ACPI 2.0 support enabled in the BIOS (I was reminded of this 
 because some ASUS MBs default this setting to off -- which may or may not 
 cause problems with FreeBSD)?

Yes (also, I've just tried disabling ACPI 2.0, with no luck).
___
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


lockup during probing because of a memory stick

2011-10-29 Thread deeptec...@gmail.com
If a USB mass storage device was connected when the computer was
turned on or reset and the device is left connected, then the system
locks up somewhere around the ``acpi0: A M I OEMXSDT on
motherboard'' line (not exactly deterministically at that line).
Otherwise (if the device is connected or disconnected just before
FreeBSD started booting, or if the device is nowhere near the computer
for the whole booting process), the system boots fine. I'm using a
-CURRENT kernel.

I don't recall this case happening some time ago. But now, this
happens with and without the NEW_PCIB option. I mention this because
``acpi0: A M I OEMXSDT on motherboard'' is shortly followed by
``acpi0: reservation of 0, a (3) failed'', whatever that means.
___
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: lockup during probing because of a memory stick

2011-10-29 Thread deeptec...@gmail.com
Spam:

== ``dmesg'' begins ==
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.9-CURRENT #0 r226900M: Sat Oct 29 19:06:59 CEST 2011
devhc@:/usr/obj/usr/src/sys/HQ i386
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.72-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf29  Family = f  Model = 2  Stepping = 9
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x4400CNXT-ID,xTPR
real memory  = 536870912 (512 MB)
avail memory = 513859584 (490 MB)
Event timer LAPIC quality 400
ACPI APIC Table: A M I  OEMAPIC 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP/HT): APIC ID:  1
ioapic0 Version 2.0 irqs 0-23 on motherboard
acpi0: A M I OEMXSDT on motherboard
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 1fef (3) failed
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
agp0: Intel 82865 host to AGP bridge on hostb0
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pci1: ACPI PCI bus on pcib1
vgapci0: VGA-compatible display port 0xd000-0xd0ff mem
0xd000-0xdfff,0xf7ee-0xf7ee irq 16 at device 0.0 on
pci1
drm0: ATI Radeon AP 9600 on vgapci0
info: [drm] AGP at 0xf800 64MB
info: [drm] Initialized radeon 1.31.0 20080613
vgapci1: VGA-compatible display mem
0xe000-0xefff,0xf7ef-0xf7ef at device 0.1 on pci1
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xc880-0xc89f
irq 16 at device 29.0 on pci0
usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xcc00-0xcc1f
irq 19 at device 29.1 on pci0
usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem
0xf7dffc00-0xf7df irq 23 at device 29.7 on pci0
usbus2: EHCI version 1.0
usbus2: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0
pcib2: failed to allocate initial memory window: 0xf7f0-0xfbff
pci2: ACPI PCI bus on pcib2
skc0: 3Com 3C940 Gigabit Ethernet port 0xe800-0xe8ff mem
0xf7ffc000-0xf7ff irq 22 at device 5.0 on pci2
skc0: 3Com Gigabit LOM (3C940) rev. (0x1)
sk0: Marvell Semiconductor, Inc. Yukon on skc0
sk0: Ethernet address: 00:0e:a6:35:15:91
miibus0: MII bus on sk0
e1000phy0: Marvell 88E1011 Gigabit PHY PHY 0 on miibus0
e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
pcm0: Creative CT5880-E port 0xec00-0xec3f irq 20 at device 12.0 on pci2
pcm0: eMicro EM28028 AC97 Codec
pcm0: Playback: DAC1,DAC2 / Record: ADC
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH5 UDMA100 controller port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on
pci0
ata0: ATA channel at channel 0 on atapci0
ata1: ATA channel at channel 1 on atapci0
pci0: serial bus, SMBus at device 31.3 (no driver attached)
acpi_button0: Power Button on acpi0
attimer0: AT timer port 0x40-0x43 irq 0 on acpi0
Timecounter i8254 frequency 1193182 Hz quality 0
Event timer i8254 frequency 1193182 Hz quality 100
atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0
Event timer RTC frequency 32768 Hz quality 0
atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
pmtimer0 on isa0
orm0: ISA Option ROM at iomem 0xc-0xccfff pnpid ORM on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
p4tcc0: CPU Frequency Thermal Control on cpu0
p4tcc1: CPU Frequency Thermal Control on cpu1
Timecounters tick every 1.000 msec
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
usbus2: 480Mbps High Speed USB v2.0
ugen0.1: Intel at usbus0
uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0
ugen1.1: Intel at usbus1
uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1
ugen2.1: Intel at usbus2
uhub2: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus2
ata1: DMA limited to UDMA33, controller found non-ATA66 cable
ada0 at ata0 bus 0 scbus0 target 0 lun 0
ada0: Maxtor 6Y080P0 YAR41BW0 ATA-7 device
ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes)
ada0: 78167MB (160086528 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad0
cd0 

panic: ffs_blkfree_cg: freeing free block

2011-10-28 Thread deeptec...@gmail.com
A panic occured while I was ``rm -rf''ing a large filedirectory tree
(that I just created with untar) on an old drive that I have not used
for a long time. Unfortunately I'm not 100% sure that the filesystem
was clean when I mounted it today. Could that result in such a panic?

I don't have the intermediate object files for the kernel; now I'm
building the kernel again (from the appropriate, exact sources). That
shouldn't harm debugging, should it? Meanwhile, I'll take any debug
info requests, which I'll attempt to address shortly.
___
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: panic: ffs_blkfree_cg: freeing free block

2011-10-28 Thread deeptec...@gmail.com
On Fri, Oct 28, 2011 at 3:40 PM, Bjoern A. Zeeb
bzeeb-li...@lists.zabbadoz.net wrote:
 On Fri, 28 Oct 2011, deeptec...@gmail.com wrote:
 I don't have the intermediate object files for the kernel; now I'm
 building the kernel again (from the appropriate, exact sources). That
 shouldn't harm debugging, should it? Meanwhile, I'll take any debug
 info requests, which I'll attempt to address shortly.

 Do you know at which revision the kernel was or about from when?

Of course. r226289.
___
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: panic: ffs_blkfree_cg: freeing free block

2011-10-28 Thread deeptec...@gmail.com
With object files which were built using the original kernel
configuration file (no debugging symbols included):

#kgdb kernel /var/crash/vmcore.4
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...(no debugging
symbols found)...
Attempt to extract a component of a value that is not a structure pointer.
Attempt to extract a component of a value that is not a structure pointer.
#0  0xc0687d88 in doadump ()
(kgdb) bt
#0  0xc0687d88 in doadump ()
#1  0xc0688302 in kern_reboot ()
#2  0xc0688768 in panic ()
#3  0xc07f92bf in ffs_blkfree_cg ()
#4  0xc07f9417 in ffs_blkfree ()
#5  0xc0803259 in ffs_indirtrunc ()
#6  0xc08042e1 in ffs_truncate ()
#7  0xc083171c in ufs_inactive ()
#8  0xc0712718 in vinactive ()
#9  0xc0716e2a in vputx ()
#10 0xc071affb in kern_unlinkat ()
#11 0xc071b1a6 in kern_unlink ()
#12 0xc071b1ca in sys_unlink ()
#13 0xc089c954 in syscall ()
#14 0xc0887021 in Xint0x80_syscall ()
#15 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)

wtf?

With object files which were built using a kernel configuration file
that had ``makeoptions DEBUG=-g'' inserted compared to the original
configuration file:

#kgdb kernel.debug /var/crash/vmcore.4
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...
Cannot access memory at address 0x0
(kgdb) bt
#0  0x in ?? ()

wtf?
___
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: panic: ffs_blkfree_cg: freeing free block

2011-10-28 Thread deeptec...@gmail.com
On Fri, Oct 28, 2011 at 11:16 AM, deeptec...@gmail.com
deeptec...@gmail.com wrote:
 I don't have the intermediate object files for the kernel; now I'm
 building the kernel again (from the appropriate, exact sources). That
 shouldn't harm debugging, should it?

On Sat, Oct 29, 2011 at 2:35 AM, Garrett Cooper yaneg...@gmail.com wrote:
 On Fri, Oct 28, 2011 at 4:34 PM, deeptec...@gmail.com
 deeptec...@gmail.com wrote:
 With object files which were built using the original kernel
 configuration file (no debugging symbols included):

 #kgdb kernel /var/crash/vmcore.4
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as i386-marcel-freebsd...(no debugging
 symbols found)...
 Attempt to extract a component of a value that is not a structure pointer.
 Attempt to extract a component of a value that is not a structure pointer.
 #0  0xc0687d88 in doadump ()
 (kgdb) bt
 #0  0xc0687d88 in doadump ()
 #1  0xc0688302 in kern_reboot ()
 #2  0xc0688768 in panic ()
 #3  0xc07f92bf in ffs_blkfree_cg ()
 #4  0xc07f9417 in ffs_blkfree ()
 #5  0xc0803259 in ffs_indirtrunc ()
 #6  0xc08042e1 in ffs_truncate ()
 #7  0xc083171c in ufs_inactive ()
 #8  0xc0712718 in vinactive ()
 #9  0xc0716e2a in vputx ()
 #10 0xc071affb in kern_unlinkat ()
 #11 0xc071b1a6 in kern_unlink ()
 #12 0xc071b1ca in sys_unlink ()
 #13 0xc089c954 in syscall ()
 #14 0xc0887021 in Xint0x80_syscall ()
 #15 0x0033 in ?? ()
 Previous frame inner to this frame (corrupt stack?)

 wtf?

 With object files which were built using a kernel configuration file
 that had ``makeoptions DEBUG=-g'' inserted compared to the original
 configuration file:

 #kgdb kernel.debug /var/crash/vmcore.4
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as i386-marcel-freebsd...
 Cannot access memory at address 0x0
 (kgdb) bt
 #0  0x in ?? ()

 wtf?

 Something stomped on the stack.

More like: the release build doesn't have enough debug information in
itself, and the release build is not debuggable at all using debug
objects that have been built posteriorly.

 What was the previous version of
 FreeBSD (major.minor.subminor, svn revision) at worked?

Not applicable.
The panic occured, out of nowhere, on an r226289 kernel that has been
working well and is still working well, with the exception of the
panic.
___
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

2011-09-27 Thread deeptec...@gmail.com
On Sun, Sep 25, 2011 at 3:01 PM, Fbsd8 fb...@a1poweruser.com 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: 9.0 beta2 the new bsdinstaller

2011-09-23 Thread deeptec...@gmail.com
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.
___
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


kernel build failure without BPF

2011-08-13 Thread deeptec...@gmail.com
in the following kernel configuration (notably without ``device
bfp''), i get the following kernel build error. which is either a bug,
or not; just posting in case it's in someone's interest.

 build log snippet begins 
=== pfsync (all)

cc -O2 -fno-strict-aliasing -pipe -march=pentium4 -Werror -D_KERNEL
-DKLD_MODULE -nostdinc  -I/usr/src/sys/modules/pfsync/../../contrib/pf
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/HQ/opt_global.h -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common  -I/usr/obj/usr/src/sys/HQ
-mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx
-msoft-float -ffreestanding -fstack-protector -std=iso9899:1999
-fstack-protector -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
-Wmissing-include-dirs -fdiagnostics-show-option -c
/usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c

/usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c: In
function 'pfsync_sendout':

/usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:2163:
error: 'm' undeclared (first use in this function)

/usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:2163:
error: (Each undeclared identifier is reported only once

/usr/src/sys/modules/pfsync/../../contrib/pf/net/if_pfsync.c:2163:
error: for each function it appears in.)

*** Error code 1



Stop in /usr/src/sys/modules/pfsync.

*** Error code 1

 build log snippet ends 
 kernel configuration file begins 
cpu I686_CPU
ident   HQ

#optionsSCHED_ULE   # ULE scheduler
options SCHED_4BSD
options PREEMPTION  # Enable kernel thread preemption
options INET# InterNETworking
#optionsINET6   # IPv6 communications protocols
options SCTP# Stream Control Transmission Protocol
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options MD_ROOT # MD is a potential root device
options NFSCL   # New Network Filesystem Client
options NFSD# New Network Filesystem Server
options NFSLOCKD# Network Lock Manager
options NFS_ROOT# NFS usable as /, requires NFSCL
options MSDOSFS # MSDOS Filesystem
options CD9660  # ISO 9660 Filesystem
options GEOM_LABEL  # Provides labelization
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
options COMPAT_FREEBSD6 # Compatible with FreeBSD6
options COMPAT_FREEBSD7 # Compatible with FreeBSD7
options SCSI_DELAY=1000 # Delay (in ms) before probing SCSI
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time 
extensions
options PRINTF_BUFR_SIZE=128# Prevent printf output being 
interspersed.
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options MAC # TrustedBSD MAC Framework

# To make an SMP kernel, the next two lines are needed
options SMP # Symmetric MultiProcessor Kernel
device  apic# I/O APIC

# CPU frequency control
device  cpufreq

# Bus support.
device  acpi
device  pci

# ATA controllers
device  ata # Legacy ATA/SATA controllers
options ATA_CAM # Handle legacy controllers with CAM
options ATA_STATIC_ID   # Static device numbering

# ATA/SCSI peripherals
device  scbus   # SCSI bus (required for ATA/SCSI)
device  ch  # SCSI media changers
device  da  # Direct Access (disks)
#device sa  # Sequential Access (tape etc)
device  cd  # CD
device  pass# Passthrough device (direct ATA/SCSI access)
device  ses # SCSI Environmental Services (and SAF-TE)

# atkbdc0 controls both the keyboard and the PS/2 mouse
device  atkbdc  # AT keyboard controller
device  atkbd   # AT keyboard
device  psm # PS/2 mouse

#device kbdmux  # keyboard multiplexer

device  vga

ghost files

2011-08-07 Thread deeptec...@gmail.com
as of recent times, some git rebase operations fail unexpectedly with
an error: cannot create .git/index.lock: file exists. an
investigation session was something like the following:
$ ls -l .git
the index.lock file is not in the shown list.
$ ls -l .git/index.lock
the file is listed! it's a regular file, its size is ~60KiB.
$ cat .git/index.lock
some file content is shown.
$ mv .git/index.lock .git/someplace
moving fails with: index.lock: file does not exist.
$ ee .git/index.lock
some file content is shown, which i edit and save. then the
.git/index.lock file really disappears (cat, direct ls, ee, mv, etc.
do not find the file), and the content i put in the .git/index.lock
file via ee is now in .git/index.

H$X!111

i still have some git rebase operations (which are notably
disk-active) fail from time to time with impossible reasons (for
example: something like cherry picking failed, or something like
cannot move git-rebase-new to git-rebase-todo: file does not exist).

i'd note that the hard drive is kind of old (7 years), and i recently
had the power cut during port build operations twice, although the
(UFS) filesystem is fsck-clean.

has anyone experienced anything like this?
what is the possibility of a filesystem/kernel bug or fsck bug?
___
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: ghost files

2011-08-07 Thread deeptec...@gmail.com
On Mon, Aug 8, 2011 at 12:57 AM, Doug Barton do...@freebsd.org wrote:
 On 08/06/2011 23:08, deeptec...@gmail.com wrote:
 i'd note that the hard drive is kind of old (7 years), and i recently
 had the power cut during port build operations twice, although the
 (UFS) filesystem is fsck-clean.

 Have you actually booted single user and run 'fsck -y'? That should
 probably be your next step.

yes i have already done that. but just for show i double-checked again
(single user mode, fsck -y), and the filesystem was reported to be
clean.
___
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: what is the RIGHT(TM) way to configure background DHCP?

2011-07-06 Thread deeptec...@gmail.com
(i intend the discussion to take place primarily on the
freebsd-hackers list, i'm CCing the freebsd-current list for a reason
stated below.)

(original first post:
http://lists.freebsd.org/pipermail/freebsd-questions/2011-June/231301.html)

On Mon, Jul 4, 2011 at 4:20 PM, Lowell Gilbert low...@be-well.ilk.org wrote:
 You might want to try rewording your question, because it didn't make
 any sense the first time.

very well. though the question should have made perfect sense the first time.

 [All of your examples were commented out, so
 it was no surprise that they didn't work.]

i chose to use # characters to separate rc.conf snippets from the
other sentences i wrote. though perhaps #s were an unfortunate choice,
because a # has a comment-begins-here meaning in rc.conf. in any case,
attempt 1 and attempt 2 didn't work, but attempt 3 did work, and
that rules out the use of # for comments in rc.conf. now i will use
= rc.conf snippet begins = and = rc.conf snippet ends
= instead of # characters.

 I considered trying to use my chrystal ball to guess that you needed
 SYNCDHCP in your interface config, but you had obviously read the
 manual for rc.conf(5), so that seemed unlikely...

and SYNCDHCP makes things even worse. (i have no idea what
SYNCDHCP is supposed to do, but in my experience:) SYNCDHCP makes
the boot process wait until DHCP server replies before proceeding.
SYNCDHCP is actually almost the same as DHCP, except that
SYNCDHCP waits indefinitely, while DHCP waits for at most
defaultroute_delay, and also, DHCP gets Starting network: lo0 sk0.
insert_bogus_interface_info_here printed *before* the IP address
assignment process starts, while SYNCDHCP gets Starting network:
lo0 sk0. insert_current_interface_info_here printed *after* the IP
address assignment process finishes.

so here is the question rephrased:

the boot process of my FreeBSD machines takes a relatively long time.
it spends 30 seconds idling at some point, because my network
interface (sk0) is supposed to have an IP address assigned via DHCP,
and the DHCP server on my LAN takes an extremely long time (~40
seconds) to reply to IP address requests. this is unacceptable for me;
i want the FreeBSD boot process to finish 30 seconds earlier, even if
i won't get the chance to use the network for ~40 seconds after the
booting has finished.

this was the actual case when my rc.conf had the following options
related to network interfaces:
= rc.conf snippet begins =
ifconfig_sk0=DHCP
= rc.conf snippet ends =

it took me 3 rc.conf configuration attempts to find a configuration in
which the boot process does not idle for 30 seconds.

the following was the first attempt:
= rc.conf snippet begins =
background_dhclient=YES
background_dhclient_sk0=YES
= rc.conf snippet ends =
with this configuration, the DHCP client isn't even started. ie., the
boot process does not idle at all (that's good!), but the network
interface will never receive an IP address automatically (that's very
bad!).

here is the second attempt:
= rc.conf snippet begins =
ifconfig_sk0=DHCP
background_dhclient=YES
background_dhclient_sk0=YES
= rc.conf snippet ends =
with this configuration, the DHCP client is started, but the boot
process still idles for 30 seconds at some point (as if the
background_dhclient and background_dhclient_if variables had no
effect).

the final attempt is:
= rc.conf snippet begins =
ifconfig_sk0=DHCP
defaultroute_delay=0
= rc.conf snippet ends =
this configuration works, ie., during the boot process, there is no
idling related to waiting for a DHCP server to reply. but this
configuration looks hacky.

so what is the RIGHT(TM) way to configure the boot process not to idle
much in case of a slow DHCP server, and why?

i ask this question partially because there is an rc.conf option
background_dhclient (also, background_dhclient_if), which doesn't
seem to do anything, though it should, since it exists (either that,
or the option should be removed). (there has been a recent discussion
on the freebsd-current list about rc.d parallelization; [reason for
CCing:] could recent rc.d changes have made the background_dhclient
option useless?)

i'd like to have an in-depth explanation on what effect should any
combination of the following options should have on the boot process:
defaultroute_delay=0, background_dhclient=YES,
synchronous_dhclient=YES. (for example, using both
background_dhclient=YES and synchronous_dhclient=YES seems stupid;
i need a clarification if that's not the case.) what's the explanation
if there is more than 1 network card (all of which are to have IP
addresses assigned via DHCP)?
___
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


/var/crash permissions

2011-06-26 Thread deeptec...@gmail.com
the FreeBSD Developers' Handbook recommends /var/crash to have
drwx-- permissions [1]. ``make installworld'' alters those
permissions to drwxr-x---. one of the two is trolling. which one?

[1] 
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN
___
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: pcib allocation failure

2011-06-09 Thread deeptec...@gmail.com
On Thu, Jun 9, 2011 at 3:22 PM, John Baldwin j...@freebsd.org wrote:
 Hmm, I would say 'progress' actually as it's getting better:


       map[10]: type Prefetchable Memory, range 32, base 0xe000, size 28, 
 enabled
 pcib1: attempting to grow prefetch window for 
 (0xe000-0xefff,0x1000)
       back candidate range: 0xe000-0xf000

 It at least attempts to grow it now.

 This patch is a slightly more correct fix for the same bug as above but also
 adds extra debugging so I can see why bus_adjust_resource() is failing to
 grow the window.  It won't fix it yet, but should output more debug info
 when it fails to grow the window:

see PS.

 Index: pci_pci.c
 ===
 --- pci_pci.c   (revision 222863)
 +++ pci_pci.c   (working copy)
 @@ -916,7 +934,8 @@ pcib_grow_window(struct pcib_softc *sc, struct pci

                /* Move end_free down until it is properly aligned. */
                end_free = ~(align - 1);
 -               front = end_free - count;
 +               end_free--;
 +               front = end_free - (count - 1);

                /*
                 * The resource would now be allocated at (front,
 @@ -944,7 +963,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci

                /* Move start_free up until it is properly aligned. */
                start_free = roundup2(start_free, align);
 -               back = start_free + count;
 +               back = start_free + count - 1;

                /*
                 * The resource would now be allocated at (start_free,
 @@ -957,7 +976,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
                        if (bootverbose)
                                printf(\tback candidate range: %#lx-%#lx\n,
                                    start_free, back);
 -                       back = roundup2(back, w-step) - 1;
 +                       back = roundup2(back + 1, w-step) - 1;
                        back -= rman_get_end(w-res);
                } else
                        back = 0;
 @@ -976,6 +995,11 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
                            rman_get_end(w-res));
                        if (error == 0)
                                break;
 +                       if (bootverbose)
 +                               device_printf(sc-dev,
 +                           failed to grow %s window to %#lx-%#lx: %d\n,
 +                                   w-name, rman_get_start(w-res) - front,
 +                                   rman_get_end(w-res), error);
                        front = 0;
                } else {
                        error = bus_adjust_resource(sc-dev, type, w-res,
 @@ -983,6 +1007,11 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
                            rman_get_end(w-res) + back);
                        if (error == 0)
                                break;
 +                       if (bootverbose)
 +                               device_printf(sc-dev,
 +                           failed to grow %s window to %#lx-%#lx: %d\n,
 +                                   w-name, rman_get_start(w-res),
 +                                   rman_get_end(w-res) + back, error);
                        back = 0;
                }
        }

== dmesg begins ==
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-CURRENT #0 r222709M: Sun Jun  5 20:01:55 CEST 2011
devhc@:/usr/obj/usr/src/sys/HQ i386
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.72-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf29  Family = f  Model = 2  Stepping = 9
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x4400CNXT-ID,xTPR
real memory  = 536870912 (512 MB)
avail memory = 513818624 (490 MB)
Event timer LAPIC quality 400
ACPI APIC Table: A M I  OEMAPIC 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 Version 2.0 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: A M I OEMXSDT on motherboard
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 1fef (3) failed
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
agp0: Intel 82865 host to AGP bridge on hostb0
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pci1: ACPI PCI bus on pcib1
vgapci0: VGA-compatible display port 0xd000-0xd0ff mem
0xd000-0xdfff,0xf7ee-0xf7ee irq 16 at device 0.0 

Re: pcib allocation failure

2011-06-09 Thread deeptec...@gmail.com
On Thu, Jun 9, 2011 at 8:56 PM, John Baldwin j...@freebsd.org wrote:
 On Thursday, June 09, 2011 2:07:31 pm deeptec...@gmail.com wrote:
 pcib1: attempting to grow prefetch window for 
 (0xe000-0xefff,0x1000)
       back candidate range: 0xe000-0xefff
 pcib1: failed to grow prefetch window to 0xd000-0xefff: 6

 Hmm, ENXIO is an odd error.  rman_adjust_resource() can't fail with that.

 Oh, I missed adding bus_adjust_resource() to the x86 nexus drivers. :(

 Try this patch in addition to the patch to pci_pci.c that you are already 
 using:

 Index: amd64/amd64/legacy.c
 ===
 --- amd64/amd64/legacy.c        (revision 222897)
 +++ amd64/amd64/legacy.c        (working copy)
 @@ -81,6 +81,7 @@
        DEVMETHOD(bus_read_ivar,        legacy_read_ivar),
        DEVMETHOD(bus_write_ivar,       legacy_write_ivar),
        DEVMETHOD(bus_alloc_resource,   bus_generic_alloc_resource),
 +       DEVMETHOD(bus_adjust_resource,  bus_generic_adjust_resource),
        DEVMETHOD(bus_release_resource, bus_generic_release_resource),
        DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
        DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),
 Index: dev/acpica/acpi.c
 ===
 --- dev/acpica/acpi.c   (revision 222897)
 +++ dev/acpica/acpi.c   (working copy)
 @@ -123,6 +123,8 @@
  static struct resource *acpi_alloc_resource(device_t bus, device_t child,
                        int type, int *rid, u_long start, u_long end,
                        u_long count, u_int flags);
 +static int     acpi_adjust_resource(device_t bus, device_t child, int type,
 +                       struct resource *r, u_long start, u_long end);
  static int     acpi_release_resource(device_t bus, device_t child, int type,
                        int rid, struct resource *r);
  static void    acpi_delete_resource(device_t bus, device_t child, int type,
 @@ -193,6 +195,7 @@
     DEVMETHOD(bus_set_resource,                acpi_set_resource),
     DEVMETHOD(bus_get_resource,                bus_generic_rl_get_resource),
     DEVMETHOD(bus_alloc_resource,      acpi_alloc_resource),
 +    DEVMETHOD(bus_adjust_resource,     acpi_adjust_resource),
     DEVMETHOD(bus_release_resource,    acpi_release_resource),
     DEVMETHOD(bus_delete_resource,     acpi_delete_resource),
     DEVMETHOD(bus_child_pnpinfo_str,   acpi_child_pnpinfo_str_method),
 @@ -1325,29 +1328,40 @@
  }

  static int
 -acpi_release_resource(device_t bus, device_t child, int type, int rid,
 -    struct resource *r)
 +acpi_is_resource_managed(int type, struct resource *r)
  {
 -    struct rman *rm;
 -    int ret;

     /* We only handle memory and IO resources through rman. */
     switch (type) {
     case SYS_RES_IOPORT:
 -       rm = acpi_rman_io;
 -       break;
 +       return (rman_is_region_manager(r, acpi_rman_io));
     case SYS_RES_MEMORY:
 -       rm = acpi_rman_mem;
 -       break;
 -    default:
 -       rm = NULL;
 +       return (rman_is_region_manager(r, acpi_rman_mem));
     }
 +    return (0);
 +}

 +static int
 +acpi_adjust_resource(device_t bus, device_t child, int type, struct resource 
 *r,
 +    u_long start, u_long end)
 +{
 +
 +    if (acpi_is_resource_managed(type, r))
 +       return (rman_adjust_resource(r, start, end));
 +    return (bus_generic_adjust_resource(bus, child, type, r, start, end));
 +}
 +
 +static int
 +acpi_release_resource(device_t bus, device_t child, int type, int rid,
 +    struct resource *r)
 +{
 +    int ret;
 +
     /*
      * If this resource belongs to one of our internal managers,
      * deactivate it and release it to the local pool.
      */
 -    if (rm != NULL  rman_is_region_manager(r, rm)) {
 +    if (acpi_is_resource_managed(type, r)) {
        if (rman_get_flags(r)  RF_ACTIVE) {
            ret = bus_deactivate_resource(child, type, rid, r);
            if (ret != 0)
 Index: i386/i386/legacy.c
 ===
 --- i386/i386/legacy.c  (revision 222897)
 +++ i386/i386/legacy.c  (working copy)
 @@ -86,6 +86,7 @@
        DEVMETHOD(bus_read_ivar,        legacy_read_ivar),
        DEVMETHOD(bus_write_ivar,       legacy_write_ivar),
        DEVMETHOD(bus_alloc_resource,   bus_generic_alloc_resource),
 +       DEVMETHOD(bus_adjust_resource,  bus_generic_adjust_resource),
        DEVMETHOD(bus_release_resource, bus_generic_release_resource),
        DEVMETHOD(bus_activate_resource, bus_generic_activate_resource),
        DEVMETHOD(bus_deactivate_resource, bus_generic_deactivate_resource),

alright, with that patch the machine is back in business.

== dmesg begins ==
MP Configuration Table version 1.1 found at 0xc00f1280
Table 'FACP' at 0x1ff30290
Table 'APIC' at 0x1ff30390
APIC: Found table at 0x1ff30390
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP

Re: pcib allocation failure

2011-06-08 Thread deeptec...@gmail.com
On Tue, Jun 7, 2011 at 4:35 PM, John Baldwin j...@freebsd.org wrote:
 On Monday, June 06, 2011 11:02:59 pm deeptec...@gmail.com wrote:
 On Mon, Jun 6, 2011 at 4:52 PM, John Baldwin j...@freebsd.org wrote:
  Can you try out this change.  It is a possible real solution (or at
 least a
  stopgap until we start using multipass to untangle the resource mess a bit
  further):
 [snip]

 that doesn't work. i get an allocation failure.

 It is expected to still get an allocation failure.

 Instead what the change does is avoid updating the registers for the window
 until after all the devices on the bus have been probed.

 Were you able to save a dmesg somehow from the boot with this patch?

== dmesg begins ==
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-CURRENT #0 r222709M: Sun Jun  5 20:01:55 CEST 2011
devhc@:/usr/obj/usr/src/sys/HQ i386
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.71-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf29  Family = f  Model = 2  Stepping = 9
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x4400CNXT-ID,xTPR
real memory  = 536870912 (512 MB)
avail memory = 513818624 (490 MB)
Event timer LAPIC quality 400
ACPI APIC Table: A M I  OEMAPIC 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 Version 2.0 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: A M I OEMXSDT on motherboard
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 1fef (3) failed
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
agp0: Intel 82865 host to AGP bridge on hostb0
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pci1: ACPI PCI bus on pcib1
vgapci0: VGA-compatible display port 0xd000-0xd0ff mem
0xd000-0xdfff,0xf7ee-0xf7ee irq 16 at device 0.0 on
pci1
drm0: ATI Radeon AP 9600 on vgapci0
info: [drm] AGP at 0xf800 64MB
info: [drm] Initialized radeon 1.31.0 20080613
vgapci1: VGA-compatible display mem
0xe000-0xefff,0xf7ef-0xf7ef at device 0.1 on pci1
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xc880-0xc89f
irq 16 at device 29.0 on pci0
usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xcc00-0xcc1f
irq 19 at device 29.1 on pci0
usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem
0xf7dffc00-0xf7df irq 23 at device 29.7 on pci0
usbus2: EHCI version 1.0
usbus2: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0
pcib2: failed to allocate initial memory window: 0xf7f0-0xfbff
pci2: ACPI PCI bus on pcib2
skc0: 3Com 3C940 Gigabit Ethernet port 0xe800-0xe8ff mem
0xf7ffc000-0xf7ff irq 22 at device 5.0 on pci2
skc0: 3Com Gigabit LOM (3C940) rev. (0x1)
sk0: Marvell Semiconductor, Inc. Yukon on skc0
sk0: Ethernet address: 00:0e:a6:35:15:91
miibus0: MII bus on sk0
e1000phy0: Marvell 88E1011 Gigabit PHY PHY 0 on miibus0
e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
pcm0: Creative CT5880-E port 0xec00-0xec3f irq 20 at device 12.0 on pci2
pcm0: eMicro EM28028 AC97 Codec
pcm0: Playback: DAC1,DAC2 / Record: ADC
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH5 UDMA100 controller port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on
pci0
ata0: ATA channel 0 on atapci0
ata1: ATA channel 1 on atapci0
pci0: serial bus, SMBus at device 31.3 (no driver attached)
acpi_button0: Power Button on acpi0
attimer0: AT timer port 0x40-0x43 irq 0 on acpi0
Timecounter i8254 frequency 1193182 Hz quality 0
Event timer i8254 frequency 1193182 Hz quality 100
atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0
Event timer RTC frequency 32768 Hz quality 0
atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
pmtimer0 on isa0
orm0: ISA Option ROM at iomem 0xc-0xccfff pnpid ORM on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
p4tcc0: CPU Frequency Thermal Control on cpu0
p4tcc1: CPU Frequency Thermal Control on cpu1
Timecounters tick every 1.000 msec
usbus0: 12Mbps Full Speed USB v1.0

Re: pcib allocation failure

2011-06-08 Thread deeptec...@gmail.com
On Wed, Jun 8, 2011 at 7:56 PM, John Baldwin j...@freebsd.org wrote:
 Hmmm, can you revert all your changes to pci_pci.c

let me note that so far i had at most 1 of the (4) patches applied at
a time (always the last one). if u'd like me to apply multiple
patches, please send 1 combined patch.
___
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: pcib allocation failure

2011-06-08 Thread deeptec...@gmail.com
On Wed, Jun 8, 2011 at 7:56 PM, John Baldwin j...@freebsd.org wrote:
 On Wednesday, June 08, 2011 11:20:17 am deeptec...@gmail.com wrote:
 On Tue, Jun 7, 2011 at 4:35 PM, John Baldwin j...@freebsd.org wrote:
 found-       vendor=0x1002, dev=0x4170, revid=0x00
       domain=0, bus=1, slot=0, func=1
       class=03-80-00, hdrtype=0x00, mfdev=0
       cmdreg=0x0007, statreg=0x02b0, cachelnsz=4 (dwords)
       lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns)
       powerspec 2  supports D0 D1 D2 D3  current D0
       map[10]: type Prefetchable Memory, range 32, base 0xe000, size 28, 
 enabled
 pcib1: attempting to grow prefetch window for 
 (0xe000-0xefff,0x1000)
 pcib1: attempting to grow memory window for 
 (0xe000-0xefff,0x1000)

 Odd, I'm not sure why this failed.  Hmm, it seems this was always failing for
 you though in the older dmesg's though.

 Hmmm, can you revert all your changes to pci_pci.c and try just this change:

 Index: pci_pci.c
 ===
 --- pci_pci.c   (revision 222863)
 +++ pci_pci.c   (working copy)
 @@ -953,7 +975,7 @@ pcib_grow_window(struct pcib_softc *sc, struct pci
                 * ok, ensure it is properly aligned for this window.
                 * Also check for overflow.
                 */
 -               if (back = end  start_free = back) {
 +               if (back = end + 1  start_free = back) {
                        if (bootverbose)
                                printf(\tback candidate range: %#lx-%#lx\n,
                                    start_free, back);

failure.

== dmesg begins ==
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-CURRENT #0 r222709M: Sun Jun  5 20:01:55 CEST 2011
devhc@:/usr/obj/usr/src/sys/HQ i386
CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2798.72-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0xf29  Family = f  Model = 2  Stepping = 9
  
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
  Features2=0x4400CNXT-ID,xTPR
real memory  = 536870912 (512 MB)
avail memory = 513818624 (490 MB)
Event timer LAPIC quality 400
ACPI APIC Table: A M I  OEMAPIC 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ioapic0 Version 2.0 irqs 0-23 on motherboard
kbd1 at kbdmux0
acpi0: A M I OEMXSDT on motherboard
acpi0: Power Button (fixed)
acpi0: reservation of 0, a (3) failed
acpi0: reservation of 10, 1fef (3) failed
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0
cpu0: ACPI CPU on acpi0
cpu1: ACPI CPU on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
agp0: Intel 82865 host to AGP bridge on hostb0
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pci1: ACPI PCI bus on pcib1
vgapci0: VGA-compatible display port 0xd000-0xd0ff mem
0xd000-0xdfff,0xf7ee-0xf7ee irq 16 at device 0.0 on
pci1
drm0: ATI Radeon AP 9600 on vgapci0
info: [drm] AGP at 0xf800 64MB
info: [drm] Initialized radeon 1.31.0 20080613
vgapci1: VGA-compatible display mem
0xe000-0xefff,0xf7ef-0xf7ef at device 0.1 on pci1
uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xc880-0xc89f
irq 16 at device 29.0 on pci0
usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0
uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xcc00-0xcc1f
irq 19 at device 29.1 on pci0
usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1
ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem
0xf7dffc00-0xf7df irq 23 at device 29.7 on pci0
usbus2: EHCI version 1.0
usbus2: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0
pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0
pcib2: failed to allocate initial memory window: 0xf7f0-0xfbff
pci2: ACPI PCI bus on pcib2
skc0: 3Com 3C940 Gigabit Ethernet port 0xe800-0xe8ff mem
0xf7ffc000-0xf7ff irq 22 at device 5.0 on pci2
skc0: 3Com Gigabit LOM (3C940) rev. (0x1)
sk0: Marvell Semiconductor, Inc. Yukon on skc0
sk0: Ethernet address: 00:0e:a6:35:15:91
miibus0: MII bus on sk0
e1000phy0: Marvell 88E1011 Gigabit PHY PHY 0 on miibus0
e1000phy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
pcm0: Creative CT5880-E port 0xec00-0xec3f irq 20 at device 12.0 on pci2
pcm0: eMicro EM28028 AC97 Codec
pcm0: Playback: DAC1,DAC2 / Record: ADC
isab0: PCI-ISA bridge at device 31.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel ICH5 UDMA100 controller port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on
pci0
ata0

Re: pcib allocation failure

2011-06-06 Thread deeptec...@gmail.com
On Mon, Jun 6, 2011 at 4:52 PM, John Baldwin j...@freebsd.org wrote:
 Can you try out this change.  It is a possible real solution (or at least a
 stopgap until we start using multipass to untangle the resource mess a bit
 further):
[snip]

that doesn't work. i get an allocation failure.
___
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: pcib allocation failure

2011-05-28 Thread deeptec...@gmail.com
On Thu, May 26, 2011 at 3:40 PM, John Baldwin j...@freebsd.org wrote:
 Ohh, you have two devices behind this bridge that have prefetch ranges.

 As a hack, can you try this:

 Index: pci_pci.c
 ===
 --- pci_pci.c   (revision 85)
 +++ pci_pci.c   (working copy)
 @@ -162,8 +162,13 @@ pcib_write_windows(struct pcib_softc *sc, int mask
  {
        device_t dev;
        uint32_t val;
 +       uint16_t cmd;

        dev = sc-dev;
 +       cmd = pci_read_config(dev, PCIR_COMMAND, 2);
 +       if (cmd  (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
 +               pci_write_config(dev, PCIR_COMMAND,
 +                   cmd  ~(PCIM_CMD_PORTEN | PCIM_CMD_MEMEN), 2);
        if (sc-io.valid  mask  WIN_IO) {
                val = pci_read_config(dev, PCIR_IOBASEL_1, 1);
                if ((val  PCIM_BRIO_MASK) == PCIM_BRIO_32) {
 @@ -192,6 +197,8 @@ pcib_write_windows(struct pcib_softc *sc, int mask
                pci_write_config(dev, PCIR_PMBASEL_1, sc-pmem.base  16, 2);
                pci_write_config(dev, PCIR_PMLIMITL_1, sc-pmem.limit  16, 
 2);
        }
 +       if (cmd  (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
 +               pci_write_config(dev, PCIR_COMMAND, cmd, 2);
  }

  static void
 @@ -337,6 +344,9 @@ pcib_probe_windows(struct pcib_softc *sc)
                            pci_read_config(dev, PCIR_PMLIMITL_1, 2));
                        max = 0x;
                }
 +               /* XXX: Testing hack */
 +               if (device_get_unit(sc-sc_dev) == 1)

i'm assuming that sc-sc_dev should be dev (this fixes a compilation error).

 +                       sc-pmem.limit = 0xefff;
                pcib_alloc_window(sc, sc-pmem, SYS_RES_MEMORY,
                    RF_PREFETCHABLE, max);
        }

that seems to work!

btw, is my machine a test-pig for an upcoming change to the PCI bus driver?
___
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: pcib allocation failure

2011-05-22 Thread deeptec...@gmail.com
On Sat, May 21, 2011 at 3:59 PM, deeptec...@gmail.com
deeptec...@gmail.com wrote:
 On Thu, May 19, 2011 at 11:35 PM, John Baldwin j...@freebsd.org wrote:
 Index: pci_pci.c
 ===
 --- pci_pci.c   (revision 222093)
 +++ pci_pci.c   (working copy)
 @@ -162,8 +162,13 @@ pcib_write_windows(struct pcib_softc *sc, int mask
  {
        device_t dev;
        uint32_t val;
 +       uint16_t cmd;

        dev = sc-dev;
 +       cmd = pci_read_config(dev, PCIR_COMMAND, 2);
 +       if (cmd  (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
 +               pci_write_config(dev, PCIR_COMMAND,
 +                   cmd  ~(PCIM_CMD_PORTEN | PCIM_CMD_MEMEN), 2);
        if (sc-io.valid  mask  WIN_IO) {
                val = pci_read_config(dev, PCIR_IOBASEL_1, 1);
                if ((val  PCIM_BRIO_MASK) == PCIM_BRIO_32) {
 @@ -192,6 +197,8 @@ pcib_write_windows(struct pcib_softc *sc, int mask
                pci_write_config(dev, PCIR_PMBASEL_1, sc-pmem.base  16, 2);
                pci_write_config(dev, PCIR_PMLIMITL_1, sc-pmem.limit  16, 
 2);
        }
 +       if (cmd  (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
 +               pci_write_config(dev, PCIR_COMMAND, cmd, 2);
  }

  static void
 @@ -231,7 +238,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc
                    w-name, (uintmax_t)w-base, (uintmax_t)w-limit);
                w-base = max_address;
                w-limit = 0;
 +#if 0
                pcib_write_windows(sc, w-mask);
 +#endif
                return;
        }
        pcib_activate_window(sc, type);

 that seems to work.

oops, i forgot to set the AGP aperture size to 128M during testing.
that patch actually does NOT 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: pcib allocation failure

2011-05-21 Thread deeptec...@gmail.com
On Thu, May 19, 2011 at 11:35 PM, John Baldwin j...@freebsd.org wrote:
 On Thursday, May 19, 2011 12:28:46 pm deeptec...@gmail.com wrote:
 On Thu, May 19, 2011 at 2:13 PM, John Baldwin j...@freebsd.org wrote:
  Yeah, your BIOS continues to behave very poorly.  Please try this hack to
 see
  if it allows your video to still work with any AGP aperture size:
 
  Index: pci_pci.c
  ===
  --- pci_pci.c   (revision 222093)
  +++ pci_pci.c   (working copy)
  @@ -231,7 +231,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc
                     w-name, (uintmax_t)w-base, (uintmax_t)w-limit);
                 w-base = max_address;
                 w-limit = 0;
  +#if 0
                 pcib_write_windows(sc, w-mask);
  +#endif
                 return;
         }
         pcib_activate_window(sc, type);

 does not.

 Hummm, that should leave the PCI-PCI bridge unchanged until we write the new
 values in place so it's never turned off (only updated to use a smaller
 range at some point).  You could try patching write_windows to disable IO and
 memory decoding in the PCI command register while the windows are frobbed.

 Index: pci_pci.c
 ===
 --- pci_pci.c   (revision 222093)
 +++ pci_pci.c   (working copy)
 @@ -162,8 +162,13 @@ pcib_write_windows(struct pcib_softc *sc, int mask
  {
        device_t dev;
        uint32_t val;
 +       uint16_t cmd;

        dev = sc-dev;
 +       cmd = pci_read_config(dev, PCIR_COMMAND, 2);
 +       if (cmd  (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
 +               pci_write_config(dev, PCIR_COMMAND,
 +                   cmd  ~(PCIM_CMD_PORTEN | PCIM_CMD_MEMEN), 2);
        if (sc-io.valid  mask  WIN_IO) {
                val = pci_read_config(dev, PCIR_IOBASEL_1, 1);
                if ((val  PCIM_BRIO_MASK) == PCIM_BRIO_32) {
 @@ -192,6 +197,8 @@ pcib_write_windows(struct pcib_softc *sc, int mask
                pci_write_config(dev, PCIR_PMBASEL_1, sc-pmem.base  16, 2);
                pci_write_config(dev, PCIR_PMLIMITL_1, sc-pmem.limit  16, 
 2);
        }
 +       if (cmd  (PCIM_CMD_PORTEN | PCIM_CMD_MEMEN))
 +               pci_write_config(dev, PCIR_COMMAND, cmd, 2);
  }

  static void
 @@ -231,7 +238,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc
                    w-name, (uintmax_t)w-base, (uintmax_t)w-limit);
                w-base = max_address;
                w-limit = 0;
 +#if 0
                pcib_write_windows(sc, w-mask);
 +#endif
                return;
        }
        pcib_activate_window(sc, type);

that seems 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: pcib allocation failure

2011-05-19 Thread deeptec...@gmail.com
On Tue, May 17, 2011 at 10:40 PM, John Baldwin j...@freebsd.org wrote:
 On Tuesday, May 17, 2011 2:03:42 pm deeptec...@gmail.com wrote:
 On Tue, May 17, 2011 at 3:44 PM, John Baldwin j...@freebsd.org wrote:
  On Saturday, May 14, 2011 12:27:59 pm deeptec...@gmail.com wrote:
  pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
  pcib1: failed to allocate initial prefetch window: 0xd000-0xfaff
 
  the console output is cut shortly after those 2 lines (but the machine
  seems to continue booting, as i have reset'd the machine, after which
  / was found to be improperly dismounted).
 
  So it actually boots fine, but video output breaks during the boot?  Does 
  it
  ever come back or it is permanently broken until reboot?

 the video output is permanently broken until reboot (i was able to
 gather logs by using delayed rc.d scripts).

  Your BIOS is actually violating the PCI spec by assigning the same resource
  ranges to two devices on the same PCI bus (the hostb device and the AGP 
  bridge
  device).  It's also doing so unnecessarily.

 ok, i've tried changing random BIOS settings, and found that changing
 AGP Aperture Size from 128M to 64M solved the problem with the new
 PCI bus driver. (i have a computer with 512MiB of RAM and an AGP video
 card with 128MiB of RAM.) weird. any comments on that?

(also, i have noticed a ~64Mi detraction in resource ranges)

 Does it still fail to alloc the initial prefetch window in that case?

hmm! good question, there does seem to be another failure with pcib2,
although without any noticable effect on the system's functionality:
pcib2: failed to allocate initial memory window: 0xf7f0-0xfbff

for the sake of completeness, here r the logs, coming from an r222043
kernel with the new PCI bus driver:

== ``devinfo -rv'' begins ==
nexus0
  npx0
  apic0
  ram0
  I/O memory addresses:
  0x0-0x9fbff
  0x10-0x1ff2
  acpi0
  Interrupt request lines:
  9
  I/O ports:
  0x10-0x1f
  0x22-0x3f
  0x44-0x5f
  0x62-0x63
  0x65-0x6f
  0x72-0x7f
  0x80
  0x84-0x86
  0x88
  0x8c-0x8e
  0x90-0x9f
  0xa2-0xbf
  0xe0-0xef
  0x290-0x297
  0x480-0x4bf
  0x4d0-0x4d1
  0x680-0x6ff
  0x800-0x87f
  I/O memory addresses:
  0xc-0xd
  0xe-0xf
  0xfec0-0xfec00fff
  0xfed2-0xfed8
  0xfee0-0xfee00fff
  0xffb0-0xffbf
  0xfff0-0x
cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1
  p4tcc0
  cpufreq0
cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU2
  p4tcc1
  cpufreq1
pcib0 pnpinfo _HID=PNP0A03 _UID=0 at handle=\_SB_.PCI0
I/O ports:
0xcf8-0xcff
  pci0
hostb0 pnpinfo vendor=0x8086 device=0x2570 subvendor=0x1043
subdevice=0x80f2 class=0x06 at slot=0 function=0
I/O memory addresses:
0xf800-0xfbff
  agp0
pcib1 pnpinfo vendor=0x8086 device=0x2571 subvendor=0x
subdevice=0x class=0x060400 at slot=1 function=0
handle=\_SB_.PCI0.P0P1
I/O ports:
0xd000-0xdfff
I/O memory addresses:
0xd000-0xf6ff
0xf7e0-0xf7ef
  pci1
vgapci0 pnpinfo vendor=0x1002 device=0x4150
subvendor=0x17ee subdevice=0x2002 class=0x03 at slot=0 function=0
Interrupt request lines:
16
pcib1 I/O port window:
0xd000-0xd0ff
pcib1 memory window:
0xf7ee-0xf7ee
pcib1 prefetch window:
0xd000-0xdfff
  vgapm0
  drm0
vgapci1 pnpinfo vendor=0x1002 device=0x4170
subvendor=0x17ee subdevice=0x2003 class=0x038000 at slot=0 function=1
pcib1 memory window:
0xf7ef-0xf7ef
pcib1 prefetch window:
0xe000-0xefff
  drm1
uhci0 pnpinfo vendor=0x8086 device=0x24d2 subvendor=0x1043
subdevice=0x80a6 class=0x0c0300 at slot=29 function=0
handle=\_SB_.PCI0.USB1
Interrupt request lines:
16
I/O ports:
0xc880-0xc89f
  usbus0
uhub0
uhci1 pnpinfo vendor=0x8086 device=0x24d4 subvendor=0x1043
subdevice=0x80a6 class=0x0c0300 at slot=29 function=1
handle=\_SB_.PCI0.USB2
Interrupt request lines:
19
I/O ports:
0xcc00-0xcc1f
  usbus1
uhub1
  ums0 pnpinfo vendor=0x04fc product=0x0801 devclass=0x00
devsubclass=0x00 sernum= release=0x1611 intclass=0x03
intsubclass=0x01 at bus=1 hubaddr=2 port=1 devaddr=2 interface=0
ehci0 pnpinfo vendor=0x8086 device=0x24dd

Re: pcib allocation failure

2011-05-19 Thread deeptec...@gmail.com
On Thu, May 19, 2011 at 2:13 PM, John Baldwin j...@freebsd.org wrote:
 Yeah, your BIOS continues to behave very poorly.  Please try this hack to see
 if it allows your video to still work with any AGP aperture size:

 Index: pci_pci.c
 ===
 --- pci_pci.c   (revision 222093)
 +++ pci_pci.c   (working copy)
 @@ -231,7 +231,9 @@ pcib_alloc_window(struct pcib_softc *sc, struct pc
                    w-name, (uintmax_t)w-base, (uintmax_t)w-limit);
                w-base = max_address;
                w-limit = 0;
 +#if 0
                pcib_write_windows(sc, w-mask);
 +#endif
                return;
        }
        pcib_activate_window(sc, type);

does not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: pcib allocation failure

2011-05-17 Thread deeptec...@gmail.com
On Tue, May 17, 2011 at 3:44 PM, John Baldwin j...@freebsd.org wrote:
 On Saturday, May 14, 2011 12:27:59 pm deeptec...@gmail.com wrote:
 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
 pcib1: failed to allocate initial prefetch window: 0xd000-0xfaff

 the console output is cut shortly after those 2 lines (but the machine
 seems to continue booting, as i have reset'd the machine, after which
 / was found to be improperly dismounted).

 So it actually boots fine, but video output breaks during the boot?  Does it
 ever come back or it is permanently broken until reboot?

the video output is permanently broken until reboot (i was able to
gather logs by using delayed rc.d scripts).

 Your BIOS is actually violating the PCI spec by assigning the same resource
 ranges to two devices on the same PCI bus (the hostb device and the AGP bridge
 device).  It's also doing so unnecessarily.

ok, i've tried changing random BIOS settings, and found that changing
AGP Aperture Size from 128M to 64M solved the problem with the new
PCI bus driver. (i have a computer with 512MiB of RAM and an AGP video
card with 128MiB of RAM.) weird. any comments on that?
___
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: pcib allocation failure

2011-05-15 Thread deeptec...@gmail.com
On Sat, May 14, 2011 at 6:27 PM, deeptec...@gmail.com
deeptec...@gmail.com wrote:
 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
 pcib1: failed to allocate initial prefetch window: 0xd000-0xfaff

 this happens with a the r221862 kernel, but not with the r221309 kernel.
 a quick search reveals something:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=143874 (i have no idea what
 that is).

indeed, r221394 introduced the said behaviour by using a new PCI bus
driver or something. with nooptions NEW_PCIB, even the latest
sources (r221970) do not exhibit the said behaviour. i conclude that
the new PCI bus driver basically sux.
___
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


pcib allocation failure

2011-05-14 Thread deeptec...@gmail.com
pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0
pcib1: failed to allocate initial prefetch window: 0xd000-0xfaff

the console output is cut shortly after those 2 lines (but the machine
seems to continue booting, as i have reset'd the machine, after which
/ was found to be improperly dismounted).

this happens with a the r221862 kernel, but not with the r221309 kernel.
a quick search reveals something:
http://www.freebsd.org/cgi/query-pr.cgi?pr=143874 (i have no idea what
that is).
___
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