Virtualbox
Hi Has anyone managed to make Virtualbox work on 9-Current? Since installing 3.1.2-OSE VMs, all brand new, abort on startup. The last part of the log seems pertinent: 00:00:15.481 !!Assertion Failed!! 00:00:15.481 Expression: paPages[i].Phys != 0 && paPages[i].Phys != NIL_RTHCPHYS && !(paPages[i].Phys & PAGE_OFFSET_MASK) 00:00:15.481 Location : /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox/VMM/MMHyper.cpp(610) int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*, const char*, RTGCPTR64*) 00:00:15.482 i=0x0 Phys= Heap Does anyone have any ideas? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Virtualbox
=?UTF-8?Q?Bernhard_Fr=C3=B6hlich?= wrote: > > >Hi > > > >Has anyone managed to make Virtualbox work on 9-Current? Since > >installing 3.1.2-OSE VMs, all brand new, abort on startup. > > > >The last part of the log seems pertinent: > > > >00:00:15.481 !!Assertion Failed!! > >00:00:15.481 Expression: paPages[i].Phys !=3D 0 && paPages[i].Phys !=3D > NIL_RTHCPHYS && >!(paPages[i].Phys & PAGE_OFFSET_MASK) > >00:00:15.481 Location : > /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox > >/VMM/MMHyper.cpp(610) int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, > const SUPPAGE*,=20 > >const char*, RTGCPTR64*) > >00:00:15.482 i=3D0x0 Phys=3D Heap > > > >Does anyone have any ideas? > > > Thanks for the report. I've talked to Alexander Eichner and he gave me a > patch that could > fix that problem. Could you please try to build the virtualbox-ose-kmod por= > t > with that patch? > If it works we will include it in the port update coming quite soon. > > http://pastebin.ca/1808090 > > If that does not help please create a backtrace from the vbox coredump and > send the vbox.log. There is no coredump. Answers to other questions: The system is an intel atom N270. Even though the processor does not support VT-x/AMD-V, nor was VB compiled with that support, the virtual machine claims this is enabled and there's no way to turn it off. Log attached. Ian -- Ian Freislich 00:00:04.350 VirtualBox 3.1.2_OSE r56127 freebsd.x86 (Feb 23 2010 17:24:31) release log 00:00:04.350 Log opened 2010-02-24T14:09:20.811771000Z 00:00:04.351 OS Product: FreeBSD 00:00:04.351 OS Release: 9.0-CURRENT 00:00:04.351 OS Version: FreeBSD 9.0-CURRENT #16: Sun Feb 7 07:39:42 SAST 2010 i...@mini.clue.co.za:/usr/obj/usr/src/sys/APPLE 00:00:04.351 Host RAM: 2031MB RAM, available: 1370MB 00:00:04.351 Executable: /usr/local/lib/virtualbox/VirtualBox 00:00:04.351 Process ID: 38681 00:00:04.351 Package type: BSD_32BITS_GENERIC (OSE) 00:00:04.365 Your keyboard type does not appear to be known to VirtualBox. If 00:00:04.365 you would like to help us improve the product, please submit a bug 00:00:04.365 report, attach this logfile and provide information about what type 00:00:04.365 of keyboard you have and whether you are using a remote X server or 00:00:04.365 something similar. 00:00:04.365 00:00:04.365 The tables for your keyboard are: 00:00:04.365 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 00:00:04.365 0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf, 0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 00:00:04.365 0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 00:00:04.366 0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f, 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 00:00:04.366 0x38, 0x39, 0x1d, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f, 0x40, 0x41, 0x42, 0x43, 0x44, 0x145, 0x46, 0x47, 00:00:04.366 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f, 0x50, 0x51, 0x52, 0x53, 0x0, 0x138, 0x56, 0x57, 00:00:04.367 0x58, 0x147, 0x148, 0x149, 0x14b, 0x0, 0x14d, 0x14f, 0x150, 0x151, 0x152, 0x153, 0x11c, 0x11d, 0x45, 0x137, 00:00:04.367 0x135, 0x138, 0x0, 0x15b, 0x15c, 0x15d, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x138, 0x0, 0x0, 0x0, 00:00:04.368 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 00:00:04.368 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 00:00:04.368 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 00:00:04.369 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 00:00:04.369 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 00:00:04.370 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 00:00:04.370 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 00:00:04.370 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 00:00:04.371 and 00:00:04.371 NULL, 0x25, 0x32, 0x0, 0x17, 0x9, 0x24, 0x62, 0x68, 00:00:04.371 0x64, 0x66, 0x43, 0x44, 0x45, 0x46, 0x47, 0x48, 0x49, 0x4a 00:00:04.433 SUP: Loaded VMMR0.r0 (/usr/local/lib/virtualbox/VMMR0.r0) at 0xcb80f060 - ModuleInit at cb8233d0 and ModuleTerm at cb823390 00:00:04.433 SUP: VMMR0EntryEx located at cb823260, VMMR0EntryFast at cb823450 and VMMR0EntryInt at cb8224c0 00:00:04.684 VBoxSharedClipboard mode: Bidirectional 00:00:04.700 * CFGM dump * 00:00:04.700 [/] (level 0) 00:00:04.700 CSAMEnabled = 0x0001 (1) 00:00:04.700 EnablePAE= 0x (0) 00:00:04.700 HwVirtExtForced = 0x (0) 00:00:04.700 Name
dev.bce.X.com_no_buffers increasing and packet loss
Hi I have a system that is experiencing mild to severe packet loss. The interfaces are configured as follows: lagg0: bce0, bce1, bce2, bce3 lagproto lacp lagg0 then is used as the hwdev for the vlan interfaces. I have pf with a few queues for bandwidth management. There isn't that much traffic on it (200-500Mbit/s). I see only the following suspect for packet loss: dev.bce.0.com_no_buffers: 140151466 dev.bce.1.com_no_buffers: 514723247 dev.bce.2.com_no_buffers: 10454050 dev.bce.3.com_no_buffers: 369371 Most of the time, these numbers are static, but every once in a while they increase massively by several thousand, but only on 2 interfaces. The 1 minute average rate on those interfaces is 266/s and 123/s. Does anyone think this is related to the packet loss or are these counters just a red herring? Is there anything that can be done to reduce this count? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
Pyun YongHyeon wrote: > On Fri, Mar 05, 2010 at 01:20:57PM +0200, Ian FREISLICH wrote: > > Hi > > > > I have a system that is experiencing mild to severe packet loss. > > The interfaces are configured as follows: > > > > lagg0: bce0, bce1, bce2, bce3 lagproto lacp > > > > lagg0 then is used as the hwdev for the vlan interfaces. > > > > I have pf with a few queues for bandwidth management. > > > > There isn't that much traffic on it (200-500Mbit/s). > > > > I see only the following suspect for packet loss: > > > > dev.bce.0.com_no_buffers: 140151466 > > dev.bce.1.com_no_buffers: 514723247 > > dev.bce.2.com_no_buffers: 10454050 > > dev.bce.3.com_no_buffers: 369371 > > > > Most of the time, these numbers are static, but every once in a > > while they increase massively by several thousand, but only on 2 > > interfaces. The 1 minute average rate on those interfaces is 266/s > > and 123/s. > > > > Does anyone think this is related to the packet loss or are these > > counters just a red herring? Is there anything that can be done > > to reduce this count? > > > > I think this sysctl node indicates number of dropped frames in > completion processor of NetXtreme II. The counter is incremented > when the processor received a frame successfully but it couldn't > pass the frame to system as there are no available RX buffers so > completion processor dopped the received frame. > If you see mbuf shortage from netstat that would be normal. But if > system has a lot of free mbuf resources it may indicate other > issue. bce(4) may not be able to replenish controller with RX > buffer if system is suffering from high load. I don't think I've ever seen an mbuf shortage on this host, and load isn't that high, typically 12% CPU or 88% idle. That's just on 2 (of 16) cores busy. There's tons of free memory (~12G) if I need to increase the number of buffers available, but I'm not sure which tunable to use to do that. The routing table also isn't large at about 4000 prefixes. [firewall1.jnb1] ~ # netstat -m 4118/7147/11265 mbufs in use (current/cache/total) 3092/6850/9942/131072 mbuf clusters in use (current/cache/total/max) 2060/4212 mbuf+clusters out of packet secondary zone in use (current/cache) 0/678/678/65536 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/32768 9k jumbo clusters in use (current/cache/total/max) 0/0/0/16384 16k jumbo clusters in use (current/cache/total/max) 7214K/18198K/25412K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines I currently set the following in loader.conf: net.isr.maxthreads="8" net.isr.direct=0 if_igb_load="yes" kern.ipc.nmbclusters="131072" kern.maxusers="1024" Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
Pyun YongHyeon wrote:
>
> Would you show me the output of dmesg(bce(4)/brgphy(4) only) and
> the output of "pciconf -lcbv" for the controller?
[firewall1.jnb1] ~ # egrep "bce|brgphy" /var/run/dmesg.boot
bce0: mem 0xe600-0xe7ff
irq 72 at device 0.0 on pci4
miibus0: on bce0
brgphy0: PHY 1 on miibus0
brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bce0: Ethernet address: 00:1e:c9:4a:33:b9
bce0: [ITHREAD]
bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (4.0.3);
Flags (MSI|MFW); MFW (ipms 1.6.0)
bce1: mem 0xe800-0xe9ff
irq 75 at device 0.0 on pci6
miibus1: on bce1
brgphy1: PHY 1 on miibus1
brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bce1: Ethernet address: 00:1e:c9:4a:33:bb
bce1: [ITHREAD]
bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (4.0.3);
Flags (MSI|MFW); MFW (ipms 1.6.0)
bce2: mem 0xea00-0xebff
irq 33 at device 0.0 on pci8
miibus2: on bce2
brgphy2: PHY 1 on miibus2
brgphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bce2: Ethernet address: 00:1e:4f:fb:cf:c5
bce2: [ITHREAD]
bce2: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (4.0.3);
Flags (MSI|MFW); MFW (ipms 1.6.0)
bce3: mem 0xec00-0xedff
irq 37 at device 0.0 on pci10
miibus3: on bce3
brgphy3: PHY 1 on miibus3
brgphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
1000baseT-FDX, auto
bce3: Ethernet address: 00:1e:4f:fb:cf:c7
bce3: [ITHREAD]
bce3: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (4.0.3);
Flags (MSI|MFW); MFW (ipms 1.6.0)
b...@pci0:4:0:0:class=0x02 card=0x02231028 chip=0x164c14e4 rev=0x12
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)'
class = network
subclass = ethernet
bar [10] = type Memory, range 64, base 0xe600, size 33554432, enabled
cap 07[40] = PCI-X 64-bit supports 133MHz, 512 burst read, 8 split
transactions
cap 01[48] = powerspec 2 supports D0 D3 current D0
cap 03[50] = VPD
cap 05[58] = MSI supports 1 message, 64 bit enabled with 1 message
b...@pci0:6:0:0:class=0x02 card=0x02231028 chip=0x164c14e4 rev=0x12
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)'
class = network
subclass = ethernet
bar [10] = type Memory, range 64, base 0xe800, size 33554432, enabled
cap 07[40] = PCI-X 64-bit supports 133MHz, 512 burst read, 8 split
transactions
cap 01[48] = powerspec 2 supports D0 D3 current D0
cap 03[50] = VPD
cap 05[58] = MSI supports 1 message, 64 bit enabled with 1 message
b...@pci0:8:0:0:class=0x02 card=0x1f121028 chip=0x164c14e4 rev=0x12
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)'
class = network
subclass = ethernet
bar [10] = type Memory, range 64, base 0xea00, size 33554432, enabled
cap 07[40] = PCI-X 64-bit supports 133MHz, 512 burst read, 8 split
transactions
cap 01[48] = powerspec 2 supports D0 D3 current D0
cap 03[50] = VPD
cap 05[58] = MSI supports 1 message, 64 bit enabled with 1 message
b...@pci0:10:0:0: class=0x02 card=0x1f121028 chip=0x164c14e4 rev=0x12
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'Broadcom NetXtreme II Gigabit Ethernet Adapter (BCM5708)'
class = network
subclass = ethernet
bar [10] = type Memory, range 64, base 0xec00, size 33554432, enabled
cap 07[40] = PCI-X 64-bit supports 133MHz, 512 burst read, 8 split
transactions
cap 01[48] = powerspec 2 supports D0 D3 current D0
cap 03[50] = VPD
cap 05[58] = MSI supports 1 message, 64 bit enabled with 1 message
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
Pyun YongHyeon wrote: > Thanks for the info. Frankly, I have no idea how to explain the > issue given that you have no heavy load. How many cores would be involved in handling the traffic and runnig PF rules on this machine? There are 4x CPU: Quad-Core AMD Opteron(tm) Processor 8354 (2194.51-MHz K8-class CPU) In this server. I'm also using carp extensively. > I have a bce(4) patch which fixes a couple of bus_dma(9) issues as > well as fixing some minor bugs. However I don't know whether the > patch can fix the RX issue you're suffering from. Anyway, would you > give it try the patch at the following URL? > http://people.freebsd.org/~yongari/bce/bce.20100305.diff > The patch was generated against CURRENT and you may see a message > like "Disabling COAL_NOW timedout!" during interface up. You can > ignore that message. Thanks. I'll give the patch a go on Monday when there are people nearby if something goes wrong during the boot. I don't want to loose the redundancy over the week end. Otherwise, is there another interface chip we can try? It's got an igb(4) quad port in there as well, but the performance is worse on that chip than the bce(4) interface. It's also riddled with vlan and other hardware offload bugs. I had good success in the past with em(4), but it looks like igb is the PCI-e version. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
Pyun YongHyeon wrote: > On Fri, Mar 05, 2010 at 11:16:41PM +0200, Ian FREISLICH wrote: > > Pyun YongHyeon wrote: > > > Thanks for the info. Frankly, I have no idea how to explain the > > > issue given that you have no heavy load. > > > > How many cores would be involved in handling the traffic and runnig > > PF rules on this machine? There are 4x > > CPU: Quad-Core AMD Opteron(tm) Processor 8354 (2194.51-MHz K8-class CPU) > > In this server. I'm also using carp extensively. > > > > pf(4) uses a single lock for processing, number of core would have > no much benefit. What's interesting is the effect on CPU utilisation and interrupt generation that net.inet.ip.fastforwarding has: net.inet.ip.fastforwarding=1 interrupt rate is around 1/s per bce interface cpu 8.0% interrupt net.inet.ip.fastforwarding=0 interrupt rate is around 5000/s per bce interface cpu 13.0% interrupt It also appears to not drop packets, but I'll have to watch it for longer. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
Pyun YongHyeon wrote: > patch can fix the RX issue you're suffering from. Anyway, would you > give it try the patch at the following URL? > http://people.freebsd.org/~yongari/bce/bce.20100305.diff > The patch was generated against CURRENT and you may see a message > like "Disabling COAL_NOW timedout!" during interface up. You can > ignore that message. It's been running for about 1:23 on the patched driver. I'm still seeing the com_no_buffers increase: [firewall2.jnb1] ~ # sysctl dev.bce |grep com_no_buffers dev.bce.0.com_no_buffers: 5642 dev.bce.1.com_no_buffers: 497 dev.bce.2.com_no_buffers: 6260612 dev.bce.3.com_no_buffers: 4871338 Interupt rate is down now, at about 3500 per second per interface. Interestingly setting net.inet.ip.fastforwarding=0 reduces CPU consumption from 25% to 9% and less packet loss. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
Pyun YongHyeon wrote: > On Mon, Mar 08, 2010 at 04:45:20PM +0200, Ian FREISLICH wrote: > > Pyun YongHyeon wrote: > > > On Fri, Mar 05, 2010 at 11:16:41PM +0200, Ian FREISLICH wrote: > > > > Pyun YongHyeon wrote: > > > > > Thanks for the info. Frankly, I have no idea how to explain the > > > > > issue given that you have no heavy load. > > > > > > > > How many cores would be involved in handling the traffic and runnig > > > > PF rules on this machine? There are 4x > > > > CPU: Quad-Core AMD Opteron(tm) Processor 8354 (2194.51-MHz K8-class CPU ) > > > > In this server. I'm also using carp extensively. > > > > > > > > > > pf(4) uses a single lock for processing, number of core would have > > > no much benefit. > > > > What's interesting is the effect on CPU utilisation and interrupt > > generation that net.inet.ip.fastforwarding has: > > > > net.inet.ip.fastforwarding=1 > > interrupt rate is around 1/s per bce interface > > cpu 8.0% interrupt > > > > Yes, this is one of intentional change of the patch. Stock bce(4) > seems to generate too much interrupts on BCM5709 so I rewrote > interrupt handling with the help of David. sysctl nodes are also > exported to control interrupt moderation so you can change them if > you want. Default value was tuned to generate interrupts less than > 10k per second and try to minimize latencies. Can you explain the tunables please - I'm guessing it's these: dev.bce.$i.tx_quick_cons_trip_int dev.bce.$i.tx_quick_cons_trip dev.bce.$i.tx_ticks_int dev.bce.$i.tx_ticks dev.bce.$i.rx_quick_cons_trip_int dev.bce.$i.rx_quick_cons_trip dev.bce.$i.rx_ticks_int dev.bce.$i.rx_ticks -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
Pyun YongHyeon wrote: > On Tue, Mar 09, 2010 at 03:31:55PM +0200, Ian FREISLICH wrote: > > Can you explain the tunables please - I'm guessing it's these: I think I asked the wrong question. What is a "Quick BD Chain"? What relation should this number have to traffic rate. Is there a maximum and what are reasonable numbers for setting this to? I set the RX as high as 512 in 64 quanta but it made little difference to the interrupt rate. At times where we experience the packet loss and com_no_buffers increases, the interrupt rate on between 1 and 3 of the 4 bce interfaces fell from about 3200/s to 130/s. We're wondering if the switches we're using could be causing this problem - they're Dell PowerConnect 5448. I've seen complaints of random packet loss caused by these switches on the Internet. We have some new H3C 5100 series switches which we're planning on swapping for the Dells tomorrow to see if it makes a difference. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
Pyun YongHyeon wrote: > On Tue, Mar 09, 2010 at 11:55:30PM +0200, Ian FREISLICH wrote: > > I set the RX as high as 512 in 64 quanta but it made little difference > > to the interrupt rate. At times where we experience the packet > > loss and com_no_buffers increases, the interrupt rate on between 1 > > and 3 of the 4 bce interfaces fell from about 3200/s to 130/s. > > > > BD chain is just one of parameters. bce(4) controllers also provide > more advanced features that fine control interrupt moderation(TX/RX > ticks). It's hard to explain all the details so you may want to > read public data sheet of bce(4). Thanks. I'll have a read over that. I meant to state that above that whenever the interrupt rate on a controller (or several) falls off, the interrupt CPU usage climbs from about 4% to about 20%. So it seems like something is happening on host that jams up interrupt processing. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
"David Christensen" wrote: > > Yeah, but the question is why bce(4) has no available RX buffers. > > The system has a lot of available mbufs so I don't see the=20 > > root cause here. > > What's the traffic look like? Jumbo, standard, short frames? Any=20 > good ideas on profiling the code? I haven't figured out how to use > the CPU TSC but there is a free running timer on the device that > might be usable to calculate where the driver's time is spent. It looks like the traffic that provoked it was this: 10:18:42.319370 IP X.4569 > X.4569: UDP, length 12 10:18:42.319402 IP X.4569 > X.4569: UDP, length 12 10:18:42.319438 IP X.4569 > X.4569: UDP, length 12 10:18:42.319484 IP X.4569 > X.4569: UDP, length 12 10:18:42.319517 IP X.4569 > X.4569: UDP, length 12 A flurry of UDP tinygrams on an IAX2 trunk. The packet rate isn't spectacular at about 30kpps which on top of the base load of 60kpps still isn't a fantastic packet rate. The interesting thing is that while this storm was inprogress, it almost entirely excluded other traffic on the network. There have been reports of backplane congestion on the switches we use when UDP packets smaller than 400 bytes arrive within 40us of eachother. But that still doesn't explain the counter increases and high interrupt CPU usage, unless the switch was producing garbage output in response. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
Pyun YongHyeon wrote: > I successfully reproduced the issue with netperf on BCM5709. You > can use UDP frame size 1 to trigger the issue. Now I wish I had paid closer attention ages ago. I actually saw this when I benchmarked the system post purchase, but didn't investigate further. I tested and specified the hardware and that system was forwarding 1MPPS. Then the bean counters got interested in Dell and they bought something entirely different. Thanks very, very much for your interest. This is one of the reasons I love FreeBSD - invariably, the right people are available and interested. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
Pyun YongHyeon wrote: > On Wed, Mar 10, 2010 at 02:45:47PM -0800, David Christensen wrote: > > The bce(4) hardware supports a linked list of pages for RX > > buffer descriptors. The stock build supports 2 pages (RX_PAGES) > > with a total of 511 BD's per page. The hardware can support a > > maximum of 64K BD's but that would be an unnecessarily large > > amount of mbufs for an infrequent problem. I think that depends on how you define infrequent. Our use case is a largish core router. It's highly likely that we'll see this again and again in various packet storms on our network. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: dev.bce.X.com_no_buffers increasing and packet loss
"David Christensen" wrote: > > Pyun YongHyeon wrote: > > > On Wed, Mar 10, 2010 at 02:45:47PM -0800, David Christensen wrote: > > > > The bce(4) hardware supports a linked list of pages for RX buffer=20 > > > > descriptors. The stock build supports 2 pages (RX_PAGES) with a=20 > > > > total of 511 BD's per page. The hardware can support a=20 > > maximum of=20 > > > > 64K BD's but that would be an unnecessarily large amount of mbufs=20 > > > > for an infrequent problem. > >=20 > > I think that depends on how you define infrequent. Our use=20 > > case is a largish core router. It's highly likely that we'll=20 > > see this again and again in various packet storms on our network. > >=20 > > Are the packet storms always always from the same host or do they come > from multiple hosts? The hardware supports RSS which can spread the > network load across multiple receive queues and multiple CPU cores, but > only when the traffic is spread across several hosts. (The current > bce(4) driver doesn't include support for RSS.) If a storm of > small frames comes from a single host then almost all adapters will be > challenged to handle the flow. In this case the storm only involved 2 hosts. While it's an exceptional circumstance it isn't unusual in our environment (core router in a datacenter). Fortuately we controlled both machines in this instance. Perhaps if the load is spread across more CPUs, then perhaps only those flows unlucky to hash to the CPU handling the storm will be degraded. That is a marginally better situation than all flows being degraded. From the sounds of it RSS isn't the cure for this particular situation, but may improve performance in general. It does sound like reworking the buffer will solve the problem. Perhaps having a 2 recieve rings so that once one ring is available for processing, the other ready filled and clear ring can be used for recieving frames. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
Hi I originally wasn't going to weigh in on this, but: 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 COMPAT_FREEBSD32 Thanks for the advance notice that FreeBSD will be EoL before RELENG_32. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
Hi siba_b...@pci0:1:0:0: class=0x028000 card=0x1508103c chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)' class = network With a fresh -CURRENT and: 72 0xcb104000 9000 siba_bwn.ko 101 0xcb118000 2c000bwn_v4_lp_ucode.ko 112 0xcb144000 3000 firmware.ko 131 0xcb2e 32000if_bwn.ko This NIC works great. You made my day. It even obeys the wireless on-off switch on the front of my netbook. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
Buganini wrote: > Hi, I got a Lenovo G450 with > siba_b...@pci0:4:0:0: class=0x028000 card=0x04b514e4 chip=0x431514e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)' > class = network > > > 4315 is not in supported list, but however the driver took the device > bwn_v4_lp_ucode.ko was not loaded automatically, so I loaded it > manually ifconfig scan seem freeze, I can `ifconfig list scan` later > and found access point correctly, but I can't associate with them, it > just keep scanning channels. I found that if I 'ifconfig wlan0 destroy' followed by 'ifconfig wlan0 create wlandev bwn0' it works. /etc/rc.conf: --- wlans_bwn0="wlan0" ifconfig_wlan0="WPA DHCP" --- The corollery is that it doesn't work first time on reboot. I need to either '/etc/rc.d/netif restart' and if that panics the machine, destroy wlan0 and then restart netif. Then wlan0/bwn0 associates correctly with this device. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Virtualbox
Ian FREISLICH wrote: > > >Has anyone managed to make Virtualbox work on 9-Current? Since > > >installing 3.1.2-OSE VMs, all brand new, abort on startup. > > > > > >The last part of the log seems pertinent: > > > > > >00:00:15.481 !!Assertion Failed!! > > >00:00:15.481 Expression: paPages[i].Phys !=3D 0 && paPages[i].Phys !=3D > > NIL_RTHCPHYS && >!(paPages[i].Phys & PAGE_OFFSET_MASK) > > >00:00:15.481 Location : > > /usr/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox > > >/VMM/MMHyper.cpp(610) int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, > > const SUPPAGE*,=20 > > >const char*, RTGCPTR64*) > > >00:00:15.482 i=3D0x0 Phys=3D Heap Just wanted to report that -CURRENT compiled yesterday and Virtuabox compiled last night work. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ANY-ONE-ELSE? ntpd+oncore+i386 doesn't work
Hi
The oncore ntp driver worked fine in my Athlon64 machine running
FreeBSD-amd64. I've tried it on a VIA-C7 and a Pentium-M based
board with an onboard serial port.
The following patch from Russell J. Yount fixes (bandaids) the issue:
Index: /usr/src/contrib/ntp/ntpd/refclock_oncore.c
===
RCS file: /home/ncvs/src/contrib/ntp/ntpd/refclock_oncore.c,v
retrieving revision 1.2
diff -u -d -r1.2 refclock_oncore.c
--- /usr/src/contrib/ntp/ntpd/refclock_oncore.c 22 Aug 2008 15:58:00 -
1.2
+++ /usr/src/contrib/ntp/ntpd/refclock_oncore.c 21 Apr 2010 08:33:55 -
@@ -1127,7 +1127,7 @@
*/
FILE*fd;
- char*cp, *cc, *ca, line[100], units[2], device[20], Msg[160], **cpp;
+ char*cp, *cc, *ca, line[100], units[2], device[32], Msg[160], **cpp;
char*dirs[] = { "/etc/ntp", "/etc", 0 };
int i, sign, lat_flg, long_flg, ht_flg, mode, mask;
double f1, f2, f3;
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ANY-ONE-ELSE? ntpd+oncore+i386 doesn't work
Ollivier Robert wrote: > According to Ian FREISLICH: > > The oncore ntp driver worked fine in my Athlon64 machine running > > FreeBSD-amd64. I've tried it on a VIA-C7 and a Pentium-M based > > board with an onboard serial port. > > Can you open a bug on bugs.ntp.org with the patch please? I'd rather have > upstream fix it properly. Thanks. > > > The following patch from Russell J. Yount fixes (bandaids) the issue: > > Just a bigger buffer then? Well, yeah: /dev/oncore.serial.0\0 is 21 chars https://bugs.ntp.org/show_bug.cgi?id=1389 Fixed in 4.2.5p248 and later. Seems FreeBSD has lagged somewhat: version="ntpd 4.2.4p5-a (1)" Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
Weongyo Jeong wrote: > > > The corollery is that it doesn't work first time on reboot. ??I need > > > to either '/etc/rc.d/netif restart' and if that panics the machine, > > > destroy wlan0 and then restart netif. > > > > > > Then wlan0/bwn0 associates correctly with this device. > > If you're a CURRENT user could you please show me the result of `netstat > -ni' after updating latest CURRENT and keeping scanning channels? [mini] /usr/home/ianf $ netstat -niI bwn0 NameMtu Network Address Ipkts Ierrs IdropOpkts Oerrs Coll bwn0 2290 00:26:5e:57:23:33 913 0 0 537 0 0 [mini] /usr/home/ianf # ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:26:5e:57:23:33 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 MHz 11g) country US authmode WPA privacy ON deftxkey UNDEF txpower 30 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL [mini] /usr/home/ianf $ ifconfig wlan0 list scan SSID/MESH IDBSSID CHAN RATE S:N INT CAPS quasar 00:30:4f:58:bf:941 54M -108:-95 100 EP WPA WME 00:1f:33:01:76:f4 11 54M -137:-95 100 EPS WPA WME ATH It's not scanning. Now: [mini] /usr/home/ianf # ifconfig wlan0 destroy [mini] /usr/home/ianf # /etc/rc.d/netif restart [mini] /usr/home/ianf # ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:26:5e:57:23:33 inet 10.0.2.232 netmask 0xff00 broadcast 10.0.2.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid quasar channel 1 (2412 MHz 11g) bssid 00:30:4f:58:bf:94 country US authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit txpower 30 bmiss 7 scanvalid 450 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS wme roaming MANUAL Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: if_alc trouble
Pyun YongHyeon wrote: > I'm working on it but I was not able to reproduce the issue on my > AR8131/AR8132/AR8151/AR8152 sample boards. However it seems AR8132 > is the only controller that shows this issue and I vaguely remember > a couple of users reported the issue. > I'll update PR 148772 if I manage to find some clue. I have the same problem with the alc on my compaq mini. Perhaps it is related to the PHY mismatch. For some reason they coupled a GE PHY with a FE controller. I need to stop my switch advertising 1000M for the laptop to autonegotiate the link speed. alc0: port 0xec80-0xecff mem 0xfebc-0xfebf irq 17 at device 0.0 on pci2 alc0: 15872 Tx FIFO, 15360 Rx FIFO alc0: Using 1 MSI message(s). miibus0: on alc0 atphy0: PHY 0 on miibus0 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto alc0: Ethernet address: 00:25:b3:7e:b7:2d alc0: [FILTER] Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: if_alc trouble
Kurt Jaeger wrote: > Hi! > > > Pyun YongHyeon wrote: > > > I'm working on it but I was not able to reproduce the issue on my > > > AR8131/AR8132/AR8151/AR8152 sample boards. However it seems AR8132 > > > is the only controller that shows this issue and I vaguely remember > > > a couple of users reported the issue. > > > I'll update PR 148772 if I manage to find some clue. > > > > I have the same problem with the alc on my compaq mini. Perhaps > > it is related to the PHY mismatch. For some reason they coupled a > > GE PHY with a FE controller. I need to stop my switch advertising > > 1000M for the laptop to autonegotiate the link speed. > > I had it on a 10/100 hub, still observed the problem. I meant that the problem is the wierd PHY/MAC arangement on this chip, not what it's plugged into. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
bwn(0) BCM4315/BCM22062000 up for grabs (driver devs only)
Hi This device is up for grabs for a willing driver developer. It's a mini PCI-express half length card. siba_b...@pci0:1:0:0: class=0x028000 card=0x1508103c chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)' class = network It does the following: Aug 12 20:48:24 mini kernel: bwn0: need multicast update callback Aug 12 20:48:25 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) Aug 12 20:48:27 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) Aug 12 20:48:28 mini kernel: bwn0: need multicast update callback Aug 12 20:48:28 mini kernel: bwn0: need multicast update callback Aug 12 20:48:28 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) Aug 12 20:48:30 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) Aug 12 20:51:39 mini kernel: bwn0: need multicast update callback After about 20 minutes I start seeing packet loss at about 5%. Within a few minutes packet loss increases to 100%. Contact me off list if you're interested. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
AR9280 "bb hang" and other
Hi I recently managed to hack my HP/Compaq BIOS to bypass the RF Whitelist and replace the (crappy) bwn interface with a (decent) ath card. There are a few things - 1. The card has AR5B93 printed on the label, but its detected as: a...@pci0:1:0:0:class=0x028000 card=0x663211ad chip=0x002a168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'Atheros AR5B91 Wireless Network Adapter (0001)' class = network ath0: mem 0xfeaf-0xfeaf irq 16 at device 0.0 on pci1 ath0: [MPSAFE] ath0: [ITHREAD] ath0: AR9280 mac 128.2 RF5133 phy 13.0 Everything I've read suggests it's actually an Atheros 9281. It's possible that the label is wrong. I'm reluctant to desolder the RF shield on the spare card I ordered to see what's actually printed on the chip. 2. I'm getting these messages fairly often. Transmission stops briefly around these times: Aug 17 08:58:47 mini kernel: ath0: bb hang detected (0x80) Aug 17 09:01:59 mini kernel: ath0: bb hang detected (0x80) Aug 17 09:05:47 mini kernel: ath0: hardware error; resetting Aug 17 09:05:47 mini kernel: ath0: 0x 0x2000 0x, 0x 0x 0x Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AR9280 "bb hang" and other
Rui Paulo wrote: > > On 17 Aug 2010, at 09:17, Ian FREISLICH wrote: > > 2. I'm getting these messages fairly often. Transmission stops > > briefly around these times: > >=20 > > Aug 17 08:58:47 mini kernel: ath0: bb hang detected (0x80) > > Aug 17 09:01:59 mini kernel: ath0: bb hang detected (0x80) > > Aug 17 09:05:47 mini kernel: ath0: hardware error; resetting > > Aug 17 09:05:47 mini kernel: ath0: 0x 0x2000 0x, = > 0x 0x 0x > > Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting > >=20 > > BB hangs are a problem with the 9280 but I don't know how to fix. Do you have a card to play with? (Since I'm offering hardware at the moment) > Hardware errors shouldn't happen, but this might mean you have very = > aggressive power reduction settings (ACPI C3, etc.) that are interfering = > with the atheros card. This has happened to me in the past. I don't think it's that: hw.acpi.cpu.cx_lowest: C1 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AR9280 "bb hang" and other
Ian FREISLICH wrote: > Rui Paulo wrote: > > > > BB hangs are a problem with the 9280 but I don't know how to fix. > > Do you have a card to play with? (Since I'm offering hardware at the moment) > > > Hardware errors shouldn't happen, but this might mean you have very = Replying to myself - Just got this error: ath0: ath_chan_set: unable to reset channel 3 (2422 MHz, flags 0x480), hal status 14 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AR9280 "bb hang" and other
Rui Paulo wrote: > On 17 Aug 2010, at 09:17, Ian FREISLICH wrote: > > Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting > > Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting > > BB hangs are a problem with the 9280 but I don't know how to fix. > Hardware errors shouldn't happen, but this might mean you have > very aggressive power reduction settings (ACPI C3, etc.) that are > interfering with the atheros card. This has happened to me in the > past. Now, I've made 2 changes so I'm not sure which affected it: 1. I replaced the card with an AR9285 a...@pci0:1:0:0: class=0x028000 card=0x7167144f chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'Atheros AR9285 Wireless LAN 802.11 a/b/g/n Controller (AR928x)' class = network 2. I changed the channel on our AP. (there were 2 other nearby APs on the same channel). I noticed that I got a lot more bb hangs at the office compared to home - there are a lot more APs nearby: [mini] /usr/home/ianf $ ifconfig wlan0 scan SSID/MESH IDBSSID CHAN RATE S:N INT CAPS Ignition00:26:bb:78:b4:916 54M -89:-96 100 EPS RSN HTCAP WPA WME Eco Impact 00:22:3f:55:80:bc 11 54M -92:-96 100 EP HTCAP WPS WPA WME Viic00:14:6c:49:3f:1c 11 54M -92:-96 100 EPS WPA ATH WME cluelan 00:30:4f:58:bf:967 54M -72:-96 100 EPS WPA ATH WME PRIVATE LABEL 00:19:70:05:28:c43 54M -79:-96 100 EP WPA WME blinkbroom1 00:18:4d:1c:8e:3a5 54M -89:-96 100 EPS WPA Sasman 00:26:f2:46:2c:de1 54M -93:-96 100 EP WME cocoa 00:26:f2:3d:aa:133 54M -94:-96 200 EPS WME HTCAP ATH CareCross 30:46:9a:1e:b0:ca8 54M -35:-96 100 EPS RSN WPA We're "cluelan" and we were on channel 3. Previously, I was seeing a hang every 10 minutes or so, since changing the channel to a "free" one, I haven't had a hang in the last 40 minutes. The only bb hang I've had was when I deactivated the RF switch on netbook and that was a semi-expected result. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: AR9280 "bb hang" and other
Adrian Chadd wrote: > Can you please change one at a time and see which affected it? Looking at my logs: startup: Aug 18 09:41:40 mini kernel: wlan0: Ethernet address: b4:82:fe:72:16:09 Aug 18 09:41:41 mini kernel: wlan0: link state changed to UP ?: Aug 18 09:45:25 mini kernel: ath0: bb hang detected (0x80), resetting RF switch off: Aug 18 09:49:50 mini kernel: ath0: bb hang detected (0x80), resetting Aug 18 09:50:13 mini kernel: wlan0: link state changed to DOWN RF switch on: Aug 18 09:50:13 mini kernel: wlan0: link state changed to UP AP changed channels Aug 18 09:54:40 mini kernel: ath0: bb hang detected (0x80), resetting wlan0 destroy: Aug 18 09:56:31 mini kernel: wlan0: link state changed to DOWN Aug 18 09:56:31 mini dhclient[1300]: Interface wlan0 no longer appears valid. wlan0 create: Aug 18 09:56:33 mini kernel: wlan0: Ethernet address: b4:82:fe:72:16:09 Aug 18 09:56:36 mini kernel: wlan0: link state changed to UP It really looks likes like it's signal related, not card related because this card still got a signal related bb hang before the channel change, but not after. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fusefs-kmod broken?
Hans Petter Selasky wrote:
> Do you have all the drivers you need in the kernel?
>
> ./uart/uart.h:extern struct uart_class uart_z8530_class __attribute__((weak))
;
> ./uart/uart_bus_scc.c: sc->sc_class = &uart_z8530_class;
> ./uart/uart_cpu_powerpc.c: class = &uart_z8530_class;
> ./uart/uart_cpu_powerpc.c: class = &uart_z8530_class;
> ./uart/uart_cpu_sparc64.c: class = &uart_z8530_class;
> ./uart/uart_dev_z8530.c:struct uart_class uart_z8530_class = {
> ./uart/uart_subr.c: &uart_z8530_class,
What drivers do you sugest? These are what's configured.
device ucom
device uplcom
device uart# 8250, 16[45]50 based serial ports
device puc
The 2 DS2480 (1-wire bus masters) are on 2 PL2303 usb serial ports.
Reading the devices works fine:
[brane] /1-wire # ls
10.0ADC53010800 10.AB2D4C010800 26.1D82B500 bus.0 structure
10.174637010800 10.BD4437010800 26.2882B500 bus.1 system
10.19D24C010800 10.E32C4C010800 29.83290300 settingsuncached
10.4A6237010800 1D.33F00D00 29.A52A0300 simultaneous
10.725A4C010800 1D.6A560B00 alarm statistics
[brane] /1-wire # cat 10.0ADC53010800/temperature
22.1875
It's writing to the 29.A52A0300 or 29.83290300 PIO registers
that results in the panic.
[brane] /1-wire # ls 29.A52A0300
LCD_H PIO.ALL latch.4 r_address sensed.7
LCD_M PIO.BYTElatch.5 r_idsensed.ALL
PIO.0 address latch.6 r_locator sensed.BYTE
PIO.1 crc8latch.7 sensed.0set_alarm
PIO.2 family latch.ALL sensed.1strobe
PIO.3 id latch.BYTE sensed.2type
PIO.4 latch.0 locator sensed.3
PIO.5 latch.1 por sensed.4
PIO.6 latch.2 power sensed.5
PIO.7 latch.3 present sensed.6
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fusefs-kmod broken?
John Baldwin wrote:
> The uart thing is a red herring, notice the actual PC value is '0'. Something
> in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35' in
> kgdb would be a good start of where to look.
(kgdb) l *kern_open+0x35
0xc0649ce5 is in kern_open (/usr/src/sys/kern/vfs_syscalls.c:1040).
1035kern_open(struct thread *td, char *path, enum uio_seg pathseg, int
flags,
1036int mode)
1037{
1038
1039return (kern_openat(td, AT_FDCWD, path, pathseg, flags, mode));
1040}
1041
1042int
1043kern_openat(struct thread *td, int fd, char *path, enum uio_seg pathseg,
1044int flags, int mode)
That's what my reading seemed indicate. I had to downgrade the
system back to 8.0-STABLE at around 21 April 2010, to get the system
working.
I'm currently doing a binary search to find offending commit, since
CURRENT and STABLE panic reliably, and in the same way I'm sure
that the problem is common to both.
I'm down to a window of 9 hours. My money is currently on:
Working file: sys/kern/vfs_syscalls.c
Approved by:re (bz)
revision 1.487.2.7
date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15
SVN rev 207270 on 2010-04-27 10:47:54Z by kib
MFC r206547:
Handle a case in kern_openat() when vn_open() change file type from
DTYPE_VNODE.
----
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fusefs-kmod broken?
Ian FREISLICH wrote:
> John Baldwin wrote:
> > The uart thing is a red herring, notice the actual PC value is '0'. Someth
ing
> > in kern_open() invoked a NULL function pointer. Doing 'l *kern_open+0x35'
in
> > kgdb would be a good start of where to look.
>
> (kgdb) l *kern_open+0x35
> 0xc0649ce5 is in kern_open (/usr/src/sys/kern/vfs_syscalls.c:1040).
> 1035kern_open(struct thread *td, char *path, enum uio_seg pathseg, int fl
ags,
> 1036int mode)
> 1037{
> 1038
> 1039return (kern_openat(td, AT_FDCWD, path, pathseg, flags, mode)
);
> 1040}
> 1041
> 1042int
> 1043kern_openat(struct thread *td, int fd, char *path, enum uio_seg paths
eg,
> 1044int flags, int mode)
>
> That's what my reading seemed indicate. I had to downgrade the
> system back to 8.0-STABLE at around 21 April 2010, to get the system
> working.
>
> I'm currently doing a binary search to find offending commit, since
> CURRENT and STABLE panic reliably, and in the same way I'm sure
> that the problem is common to both.
>
> I'm down to a window of 9 hours. My money is currently on:
>
> Working file: sys/kern/vfs_syscalls.c
> Approved by:re (bz)
>
> revision 1.487.2.7
> date: 2010/04/27 10:47:54; author: kib; state: Exp; lines: +2 -15
> SVN rev 207270 on 2010-04-27 10:47:54Z by kib
>
> MFC r206547:
> Handle a case in kern_openat() when vn_open() change file type from
> DTYPE_VNODE.
>
Confirmed.
1.487.2.6 doesn't panic, 1.487.2.7 does. This is the change that
results in the panic.
--- sys/kern/vfs_syscalls.c 16 Apr 2010 08:32:08 - 1.487.2.6
+++ sys/kern/vfs_syscalls.c 27 Apr 2010 10:47:54 - 1.487.2.7
@@ -35,7 +35,7 @@
*/
#include
-__FBSDID("$FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.487.2.6 2010/04/16
08:32:08 kib Exp $");
+__FBSDID("$FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.487.2.7 2010/04/27
10:47:54 kib Exp $");
#include "opt_compat.h"
#include "opt_kdtrace.h"
@@ -1047,8 +1047,6 @@
struct filedesc *fdp = p->p_fd;
struct file *fp;
struct vnode *vp;
- struct vattr vat;
- struct mount *mp;
int cmode;
struct file *nfp;
int type, indx, error;
@@ -1141,7 +1139,7 @@
}
VOP_UNLOCK(vp, 0);
- if (flags & (O_EXLOCK | O_SHLOCK)) {
+ if (fp->f_type == DTYPE_VNODE && (flags & (O_EXLOCK | O_SHLOCK)) != 0) {
lf.l_whence = SEEK_SET;
lf.l_start = 0;
lf.l_len = 0;
@@ -1158,18 +1156,7 @@
atomic_set_int(&fp->f_flag, FHASLOCK);
}
if (flags & O_TRUNC) {
- if ((error = vn_start_write(vp, &mp, V_WAIT | PCATCH)) != 0)
- goto bad;
- VATTR_NULL(&vat);
- vat.va_size = 0;
- vn_lock(vp, LK_EXCLUSIVE | LK_RETRY);
-#ifdef MAC
- error = mac_vnode_check_write(td->td_ucred, fp->f_cred, vp);
- if (error == 0)
-#endif
- error = VOP_SETATTR(vp, &vat, td->td_ucred);
- VOP_UNLOCK(vp, 0);
- vn_finished_write(mp);
+ error = fo_truncate(fp, 0, td->td_ucred, td);
if (error)
goto bad;
}
mount:
/dev/fuse0 on /1-wire (fusefs, local, synchronous)
Something about it has a write
echo -n 192 > /1-wire/29.A52A0300/PIO.BYTE
Panic. But not like:
echo -n 192 >> /1-wire/29.A52A0300/PIO.BYTE
I suspect the truncate is not safe. Or, at least this fuse presented
fite cannot be truncated.
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: fusefs-kmod broken?
Kostik Belousov wrote:
>
> --7hK5U8dVDlZxii7z
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, Aug 23, 2010 at 03:47:23PM +0200, Ed Schouten wrote:
> > * Kostik Belousov wrote:
> > > On Mon, Aug 23, 2010 at 03:35:55PM +0200, Ed Schouten wrote:
> > > > * Kostik Belousov wrote:
> > > > > Which most likely means that fusesfs filled its own struct fileops
> > > > > without properly initializing fo_truncate member.
> > > >=20
> > > > It's a bit misleading that cdevs automatically patch the table, while
> > > > the fileops don't. Maybe it would be a good idea to patch finit() to
> > > I do not understand your first sentence. Would you please elaborate ?
> >=20
> > Say, you create a cdev, if you don't implement all ops, it will check
> > for null pointers and return error codes accordingly. This doesn't
> > happen for fileops, which is probably one of the reasons why people
> > sometimes forget to implement them.
> >=20
> > Wouldn't it be better to prevent this form of footshooting by adding
> > assertions? This will add some overhead for any file descriptor created,
> > but a kernel with INVARIANTS isn't meant to be fast.
> Thanks, I see it now.
>
> The cdev interface definitely falls into the public kernel interface.
> Having to fill all cdevsw methods for a random driver is too much
> burden put on the several dozens maintainers.
>
> On the other hand, file level is not much widely used by third-party
> components, and even in-tree code implements only ten different file
> types.
>
> I would not object loudly if someone put such checks as proposed
> under INVARIANTS, but also I do not see a real point in having them.
> Might be slightly better to put the checks, again under INVARIANTS,
> in the fo_XXX() wrappers.
So, in this case is the fusefs module broken? I'm guessing it is.
I don't like the way fuse_fileops is initialised in fuse4bsd. I
would prefer for the struct to be zeroed and then the fo_xxx
implimented bits set as appropriate. That way when the struct is
changed, you don't get stung again.
Patch attached to that makes fusefs-kmod not blowup kernels post this change.
Ian
--
Ian Freislich
Index: files/patch-fuse_module__fuse_vnops.c
===
RCS file:
/home/ncvs/ports/sysutils/fusefs-kmod/files/patch-fuse_module__fuse_vnops.c,v
retrieving revision 1.4
diff -u -d -r1.4 patch-fuse_module__fuse_vnops.c
--- files/patch-fuse_module__fuse_vnops.c 30 Oct 2008 15:36:35 -
1.4
+++ files/patch-fuse_module__fuse_vnops.c 23 Aug 2010 14:27:17 -
+@@ -214,6 +214,7 @@
+ * following fields are filled from vnops, but "vnops.foo" is not
+ * legitimate in a definition, so we set them at module load time
+*/
++ .fo_truncate = NULL,
+ .fo_ioctl= NULL,
+ .fo_poll = NULL,
+ .fo_kqfilter = NULL,
+@@ -799,8 +800,11 @@
struct vnode *vp = ap->a_vp;
struct vattr *vap = ap->a_vap;
struct ucred *cred = ap->a_cred;
@@ -13,7 +21,7 @@
struct fuse_dispatcher fdi;
struct timespec uptsp;
int err = 0;
-@@ -871,7 +874,11 @@
+@@ -871,7 +875,11 @@
fuse_access(ap)
struct vop_access_args /* {
struct vnode *a_vp;
@@ -25,7 +33,7 @@
struct ucred *a_cred;
struct thread *a_td;
} */ *ap;
-@@ -886,7 +893,13 @@
+@@ -886,7 +894,13 @@
else
facp.facc_flags |= FACCESS_DO_ACCESS;
@@ -40,7 +48,7 @@
}
/*
-@@ -946,7 +959,11 @@
+@@ -946,7 +960,11 @@
/* We are to do the check in-kernel */
if (! (facp->facc_flags & FACCESS_VA_VALID)) {
@@ -53,7 +61,7 @@
if (err)
return (err);
facp->facc_flags |= FACCESS_VA_VALID;
-@@ -1929,7 +1946,11 @@
+@@ -1929,7 +1947,11 @@
* It will not invalidate pages which are dirty, locked, under
* writeback or mapped into pagetables.")
*/
@@ -65,7 +73,7 @@
fufh->flags |= FOPEN_KEEP_CACHE;
}
-@@ -3005,8 +3026,11 @@
+@@ -3005,8 +3027,11 @@
struct vattr *vap = ap->a_vap;
struct vnode *vp = ap->a_vp;
struct ucred *cred = ap->a_cred;
___
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: fusefs-kmod broken?
Ian FREISLICH wrote:
> So, in this case is the fusefs module broken? I'm guessing it is.
> I don't like the way fuse_fileops is initialised in fuse4bsd. I
> would prefer for the struct to be zeroed and then the fo_xxx
> implimented bits set as appropriate. That way when the struct is
> changed, you don't get stung again.
I am an idiot - that will have no effect. This patch needs to be
included in sysutils/fusefs-kmod/files
--
Ian Freislich
patch-fuse_module__fuse_main.c
--- fuse_module/fuse_main.c.orig2010-08-23 16:52:20.0 +0200
+++ fuse_module/fuse_main.c 2010-08-23 16:48:17.0 +0200
@@ -108,6 +108,7 @@
switch (what) {
case MOD_LOAD:/* kldload */
+ fuse_fileops.fo_truncate = vnops.fo_truncate;
fuse_fileops.fo_ioctl= vnops.fo_ioctl;
fuse_fileops.fo_poll = vnops.fo_poll;
fuse_fileops.fo_kqfilter = vnops.fo_kqfilter;
___
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: mfi and Dell PERC 6/i
Danilo Baio wrote: > > Scott Long wrote: > > The firmware on the controller crashed. The best I can suggest is to look > > for newer firmware (mfiutil can flash firmware) and to call LSI or Dell > > tech-support and report the problem. In the past, there have been bugs with > > patrol reads causing crashes under heavy load, so you might also look at > > disabling that option. Dell will not be interested unless the adapter is running the most recent firmware. > Intersting, patrol read is automatic and before crash show on the logs that > patrol read has started. > > I disabled this feature, rebooted the server and didn't show that firmware > error... > > I will test for some days. Dell, (maybe) Scott and I recomend that you ensure you're on the latest firmware: [firewall2] ~ # mfiutil -u0 show adapter mfi0 Adapter: Product Name: PERC 6/i Adapter Serial Number: 1122334455667788 Firmware: 6.2.0-0013 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 256M Minimum Stripe: 8K Maximum Stripe: 1M I'm sure there are bugs on this firmware too, but reading the fixes that were made between the version that came on the adapter and this version were Truely Frightening. It's trivial to update the firmware with the mfiutl program. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: One-shot-oriented event timers management
On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin wrote: > Brandon Gooch wrote: >> This latest patch causes an interrupt storm with the HPET timer on my >> system. The machine took about 8 minutes to boot and bring me to a >> login prompt. System interactivity (i.e. input from keyboard, output >> on console) was fine, but after checking the output of `systat vmstat >> -1`, I saw the interrupt rate on each HPET entry was over 120k! >> >> Can I provide any useful detail? Of course, test patches are always welcom e :) > > I was able to reproduce alike storm in some situations. > > Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch Interrupt rates are definitely reduced. [mini] /usr/home/ianf $ vmstat -i interrupt total rate irq1: atkbd01154 1 irq9: acpi010829 15 irq16: ath0 uhci3+ 16226 23 irq18: uhci2 16 0 irq19: uhci1+ 7090 10 irq20: hpet0 169288240 irq23: uhci0 ehci064 0 irq256: hdac0187 0 Total 204854291 [mini] /usr/home/ianf $ sysctl dev.cpu |grep usage dev.cpu.0.cx_usage: 0.00% 0.04% 0.80% 99.15% last 1601us dev.cpu.1.cx_usage: 0.00% 0.00% 0.65% 99.34% last 2078us Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: One-shot-oriented event timers management
Alexander Motin wrote: > Ian FREISLICH wrote: > > On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin wrote: > >> Brandon Gooch wrote: > >>> This latest patch causes an interrupt storm with the HPET timer on my > >>> system. The machine took about 8 minutes to boot and bring me to a > >>> login prompt. System interactivity (i.e. input from keyboard, output > >>> on console) was fine, but after checking the output of `systat vmstat > >>> -1`, I saw the interrupt rate on each HPET entry was over 120k! > >>> > >>> Can I provide any useful detail? Of course, test patches are always welco m > > e :) > >> I was able to reproduce alike storm in some situations. > >> > >> Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch > > > > Interrupt rates are definitely reduced. > > > > [mini] /usr/home/ianf $ vmstat -i > > interrupt total rate > > irq1: atkbd01154 1 > > irq9: acpi010829 15 > > irq16: ath0 uhci3+ 16226 23 > > irq18: uhci2 16 0 > > irq19: uhci1+ 7090 10 > > irq20: hpet0 169288240 > > irq23: uhci0 ehci064 0 > > irq256: hdac0187 0 > > Total 204854291 > > Nice. But 240 still quite a lot. Have you applied tm6292_idle.patch and > was this system idle at the moment? No, I didn't. It was reasonably idle. I missed that in the first post - because I became interested in this when Brandon Gooch reported lower power consumption. I've compiled now with this patch as well. There was one rejection: --- 2182,2189 * Ticks is updated asynchronously on a single cpu. Check here to * avoid incrementing ts_ticks multiple times in a single tick. */ + //if (ts->ts_incrtick == ticks) + //return; /* Adjust ticks for pctcpu */ ts->ts_ticks += 1 << SCHED_TICK_SHIFT; ts->ts_ltick = ticks; But, it appears to have already been applied by timers_oneshot7.patch. The vmstat -i output is the rate since boot. Currently at 240/s since boot, the instantaneous rate when idle is about 60. > > [mini] /usr/home/ianf $ sysctl dev.cpu |grep usage > > dev.cpu.0.cx_usage: 0.00% 0.04% 0.80% 99.15% last 1601us > > dev.cpu.1.cx_usage: 0.00% 0.00% 0.65% 99.34% last 2078us > > It is the first time I see in practice system reporting 4 different ACPI > C-states. What is this system? What CPU is there? Could you show me full > `sysctl dev.cpu` output? It's a compaq mini-110: CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.22-MHz 686-class CPU) dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.P001 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1600 dev.cpu.0.freq_levels: 1600/25000 1400/21875 1333/18000 1166/15750 1067/11000 933/9625 800/5000 700/4375 600/3750 500/3125 400/2500 300/1875 200/1250 100/625 dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 C4/57 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% 0.00% last 379us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.P002 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/1 C2/1 C3/17 C4/57 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% 0.00% last 4335us Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: significantly slow IPFW + NATD + amd64
Peter Reo Molnar wrote: > Hello, > > I tried setup NAT with IPFW, compiled my kernel and I found that there > is very slow connection. > After I disabled NAT and IPFW then speed was increased. > > 64-bit FreeBSD 9-CURRENT : > With IPFW: 1.2 MB/sec > Without IPFW: 33 MB/sec > > > my ipfw work with i386 (stable) without speed decreasing: > > fw.test.conf: > -f flush > add 00050 divert 8668 ip4 from any to any via re0 > add 00100 allow ip from any to any via lo0 > add 00200 deny ip from any to 127.0.0.0/8 > add 00300 deny ip from 127.0.0.0/8 to any This looks like you're using the old style NAT - divert to userland. That has always performed poorly. Perhaps not as poorly as this though. How much CPU is natd consuming? Have you considered using in-kernel NAT? See the 'NETWORK ADDRESS TRANSLATION' section in the ipfw manual. It's worth a try. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: significantly slow IPFW + NATD + amd64
Randy Bush wrote:
> Ian FREISLICH wrote:
> > Peter Reo Molnar wrote:
> > > Hello,
> > >
> > > I tried setup NAT with IPFW, compiled my kernel and I found that there
> > > is very slow connection.
> > > After I disabled NAT and IPFW then speed was increased.
> > >
> > > 64-bit FreeBSD 9-CURRENT :
> > > With IPFW: 1.2 MB/sec
> > > Without IPFW: 33 MB/sec
> > >
> > >
> > > my ipfw work with i386 (stable) without speed decreasing:
> > >
> > > fw.test.conf:
> > > -f flush
> > > add 00050 divert 8668 ip4 from any to any via re0
> > > add 00100 allow ip from any to any via lo0
> > > add 00200 deny ip from any to 127.0.0.0/8
> > > add 00300 deny ip from 127.0.0.0/8 to any
> >
> > This looks like you're using the old style NAT - divert to userland.
> > That has always performed poorly. Perhaps not as poorly as this
> > though. How much CPU is natd consuming?
> >
> > Have you considered using in-kernel NAT? See the 'NETWORK ADDRESS
> > TRANSLATION' section in the ipfw manual. It's worth a try.
>
> i never managed to figure out how to convert my pppoe nat config to ipfw
> natting.
>
> foo:
> set device PPPoE:vr0
> set MTU 1454
> accept CHAP
> enable lqr
> add default HISADDR
> nat enable yes
> nat port tcp 192.168.0.33:51332 51332
> nat port udp 192.168.0.33:51332 51332
> set authname blogovitch
> set authkey vitchoblog
>
> loop:
> set log phase chat connect lcp ipcp command
> set device localhost:pptp
> set dial
> set login
> set ifaddr 192.168.0.200 192.168.0.201 255.255.255.255
>
> clue bat solicited
I should have prefaced this with "last used ipfw in 2005". One of the
reasons for this was poor NAT performance because of all the kernel-user
and back again copies. I've always done it your way for 2 reasons:
1. In this country, PPPoE means you're using ADSL or some broadband
connection, and you can't get them fast enough that filling your
line will use more than 1% CPU doing NAT in userland.
2. The broadband in this country assigns a dynamic IP address and
until recently reset the connection every 24h, so your NAT had
to be aware of these changes and restart itself.
You can use the ppp.linkup and ppp.linkdown files to make scripts
for your ppp profiles to add and delete NAT rules and restart natd.
For instance I used to run a PPP over UDP tunnel over my PPPoE
connection to get a static IP address at home. The ppp profile
that was always on was called adsl. I had a seperate profile called
tunnel that would start only when the adsl profile had link:
ppp.linkup
---
adsl:
! sh -c "pppctl -p pass 127.0.0.1:3001 quit all; sleep 30;
/usr/sbin/ppp -unit 1 -quiet -ddial tunnel"
---
ppp.linkdown
---
[brane] /etc/ppp # cat ppp.linkdown
adsl:
! sh -c "pppctl -p pass 127.0.0.1:3001 quit all"
---
I'm sure you could coax these scripts to do what you want, but
unless you have more than 50mbps I doubt it's worth the effort.
pf just makes so much more sense for NAT, but it suffers the same
static addressing problem:
nat on vlan2 from { 41.154.7.0/24 } -> 41.161.16.1
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: One-shot-oriented event timers management
Peter Jeremy wrote: > On 2010-Sep-02 13:08:25 +0200, Ian FREISLICH wrote: > >It's a compaq mini-110: > >CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.22-MHz 686-class CPU) > > Hmmm... I have a N270 in an Aspire One. > > >dev.cpu.0.freq_levels: 1600/25000 1400/21875 1333/18000 1166/15750 1067/11= > 000 933/9625 800/5000 700/4375 600/3750 500/3125 400/2500 300/1875 200/1250= > 100/625 > > That's rather more frequencies than I would expect. Do you have > acpi_throttle enabled? If so, you might like to disable it - it's not > particularly effective (and caused regular hands on my AMD Turion > laptop). No acpi_throttle in my sysctl mib: [mini] ~ $ sysctl -a |grep acpi_throttle [mini] ~ $ I can set all of these frequencies. They don't really save any power, they just make the system slow. > >dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 C4/57 > > I'm also intrigued as to where C4 comes from. I have: > > dev.cpu.0.freq_levels: 1600/2000 1333/1533 1066/1066 800/600 > dev.cpu.0.cx_supported: C1/1 C2/1 C3/57 And I can set C4. But the acpi battery method can't determine the discharge rate so I don't know if it actually reduces power either. [mini] ~ $ acpiconf -i 0 Design capacity:5100 mAh Last full capacity: 4952 mAh Technology: secondary (rechargeable) Design voltage: 10800 mV Capacity (warn):496 mAh Capacity (low): 347 mAh Low/warn granularity: 0 mAh Warn/full granularity: 100 mAh Model number: Primary Serial number: Type: LION OEM info: Hewlett-Packard State: discharging Remaining capacity: 100% Remaining time: unknown Present rate: unknown Voltage: 12363 mV It might have something to do with the hardware verdor or bios vendor. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TCP loopback socket fusing
Fabien Thomas wrote: > Great, > > This will maybe kill the long time debate about "my loopback is slow vs > linux" > To have the best of both world what about a socket option to > enable/disable fusing: > can be useful when you need to see some connection "packetized". To chime in, I had a "slow" loopback issue earlier this week. It turned out the problem was caused by delayed ack on the loopback where the client didn't need to transmit any data to the server. It delayed each packet from the server by 100ms. After patching the server to: setsockopt(desc->accept_fd, IPPROTO_TCP, TCP_NODELAY, &x, sizeof(x)); It's now faster than on linux. Perhaps this is one of the causes of "my loopback is slow vs linux". FWIW, I couldn't find a way to turn off dealyed_ack on just loopback interface. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Port won't build because of installed conflict
Hi [mini] /usr/ports/www/firefox # make ===> firefox-3.6.10,1 conflicts with installed package(s): firefox-3.5.13,1 They install files into the same place. Please remove them first with pkg_delete(1). *** Error code 1 Stop in /usr/ports/www/firefox. *** Error code 1 But I don't want to be without the browser while I'm building the new one. Is there a reason why this conflict isn't checked at install time rather than build time? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[patch] via_dma.c
Hi
While trying to make googleearth work on a Via Epia LN board with
openchrome and GL we noticed that the X server crashed after about
30 seconds of use. I got a flood of the following messages.
Oct 26 12:13:24 test kernel: error: [drm:pid97391:via_hook_segment] *ERROR*
Paused at incorrect address. 0xe1fcf300, 0xe1fc4900 0x
Oct 26 12:13:24 test kernel: error: [drm:pid97391:via_hook_segment] *ERROR*
Paused at incorrect address. 0xe1fd0300, 0xe1fc4900 0x
Oct 26 12:13:24 test kernel: error: [drm:pid97391:via_cmdbuf_size] *ERROR*
VIA_CMDBUF_LAG timed out.
Some research showed that occasionally the GPU pauses and when the
pipe is restarted, commands are reordered and the next command after
the paused command is dropped.
I located a patch which I hand applied because every chunk failed.
It has fixed the stability issue and gpu pipe restarting issue.
I still have a problem with googleearth only displaying its image
in part of the window. It looks like the plane size is correct but
it gets the offset wrong so there is a blank on the right side the
size of the left menu pane and a blank at the bottom the size of
the window bar and menu bar at the top of the window.
Do you have any ideas how to fix this?
Ian
--
Ian Freislich
Index: sys/dev/drm/via_dma.c
===
RCS file: /home/ncvs/src/sys/dev/drm/via_dma.c,v
retrieving revision 1.2
diff -u -d -r1.2 via_dma.c
--- sys/dev/drm/via_dma.c 22 Apr 2010 18:21:25 - 1.2
+++ sys/dev/drm/via_dma.c 26 Oct 2010 15:03:04 -
@@ -119,10 +119,12 @@
uint32_t count;
hw_addr_ptr = dev_priv->hw_addr_ptr;
cur_addr = dev_priv->dma_low;
- next_addr = cur_addr + size + 512 * 1024;
+ next_addr = cur_addr + size + 64 * 1024;
count = 100;
do {
- hw_addr = *hw_addr_ptr - agp_base;
+ (void) *hw_addr_ptr;
+ DRM_MEMORYBARRIER();
+ hw_addr = (*hw_addr_ptr - agp_base);
if (count-- == 0) {
DRM_ERROR
("via_cmdbuf_wait timed out hw %x cur_addr %x
next_addr %x\n",
@@ -272,7 +274,9 @@
{
drm_via_private_t *dev_priv;
uint32_t *vb;
+#if 0
int ret;
+#endif
dev_priv = (drm_via_private_t *) dev->dev_private;
@@ -285,7 +289,12 @@
return -ENOMEM;
}
- if (DRM_COPY_FROM_USER(dev_priv->pci_buf, cmd->buf, cmd->size))
+ vb = via_check_dma(dev_priv, (cmd->size < 0x100) ? 0x102 : cmd->size);
+ if (vb == NULL) {
+ return -EAGAIN;
+ }
+
+ if (DRM_COPY_FROM_USER(vb, cmd->buf, cmd->size))
return -EFAULT;
/*
@@ -294,19 +303,15 @@
* copy it to AGP memory when ready.
*/
+#if 0
if ((ret =
via_verify_command_stream((uint32_t *) dev_priv->pci_buf,
cmd->size, dev, 1))) {
return ret;
}
- vb = via_check_dma(dev_priv, (cmd->size < 0x100) ? 0x102 : cmd->size);
- if (vb == NULL) {
- return -EAGAIN;
- }
-
memcpy(vb, dev_priv->pci_buf, cmd->size);
-
+#endif
dev_priv->dma_low += cmd->size;
/*
@@ -467,11 +472,28 @@
reader = *(dev_priv->hw_addr_ptr);
diff = (uint32_t) (ptr - reader) - dev_priv->dma_diff;
diff &= (dev_priv->dma_high - 1);
- if (diff != 0 && diff < (dev_priv->dma_high >> 1)) {
- DRM_ERROR("Paused at incorrect address. "
- "0x%08x, 0x%08x 0x%08x\n",
- ptr, reader, dev_priv->dma_diff);
- } else if (diff == 0) {
+ if (diff < (dev_priv->dma_high >> 1)) {
+ if (diff != 0) {
+ volatile uint32_t *rekick;
+
+ DRM_INFO("Paused at incorrect address. "
+ "0x%08x, 0x%08x 0x%08x. Restarting.\n",
+ ptr, reader, dev_priv->dma_diff);
+
+ /*
+* Obtain the new pause address the command
+* reader was supposed to pick up.
+*/
+
+ rekick = (volatile uint32_t *)
+ dev_priv->dma_ptr +
+ ((reader - dev_priv->dma_offset -
+ (uint32_t) dev_priv->agpAddr +
+ dev_priv->dma_diff - 4) >> 2);
+ pause_addr_lo = *rekick;
+
Re: In-kernel PPPoE
David Rhodus wrote: > Does mpd work in -current ? Last tried I, netgraph had problems with mpd. I have successfully used it on -CURRENT as late as: FreeBSD mini 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Wed Nov 17 07:11:06 SAST 2010 i...@mini:/usr/obj/usr/src/sys/APPLE i386 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: More if_ath churn coming your way!
Adrian Chadd wrote: > On 20 January 2011 13:51, Adrian Chadd wrote: > > Hi everyone, > > > > I'm in the process of merging in the non-intrusive changes to the > > if_ath code into -HEAD. > > Ok, so I lied - the ANI changes were slightly intrusive. But all in > all the code was just shuffled around a bit. > > Someone's reported that the AR9285 was once stable but now isn't. I'd > really appreciate it if others who are using AR9280/AR9285 chipsets > would test this out and get back to me. Oddly enough, I think my AR9285 uses less power now. This I do know however: at boot, it associates much much faster. I used to have to wait at least 10 seconds for "the default route interface". Now, association and DHCP blazes through without pausing. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: More if_ath churn coming your way!
Adrian Chadd wrote: > I haven't changed anything on the AR9285 codebase that would account > for the above. That maybe. The visible difference in behaviour is that when there's no traffic, the reported rate drops to 1Mbps. As soon as there's traffic it jumps to 54Mbps. > Something to keep in mind with the AR9280/AR9285 support is that I've > seen it be -very- unpredictable - sometimes it's reliable off the bat, > sometimes it's not. You have to repeat it a few times to verify that > you've actually seen a change. So far, I've had instances where it's stopped transmitting or recieving. It claims to remain associated, but restarting the wlan interface fails to reestablish the association and a list scan is empty. It only seems to happen when the laptop is running on battery. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [ath] more updates; please test (especially if you're using an AR9280)
Adrian Chadd wrote: > On 23 January 2011 23:03, Adrian Chadd wrote: > > I've done a few updates to the ath driver today. In particular, I've > > updated the register initvals used to program the AR9280. It's making > > my AR9280 here behave a lot better. > > Just as a followup - it's a -lot- better. I can't stress how much > better my AR9280 is behaving after the updates to the initvals. > > Beforehand the AR9280 would lock up after 2-3 minutes in monitor mode, > and whilst in that mode it'd miss a lot of RX packets. After the > initval update, it's been happily receiving in monitor mode for > 30 > minutes. I'm quite shocked. :) I agree. I had several lockups this morning (bb hangs) and the wlan0 interface refused to destroy and create after that. Since updating, it's been stable for the last hour. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [ath] more updates; please test (especially if you're using an AR9280)
Adrian Chadd wrote: > On 24 January 2011 17:06, Ian FREISLICH wrote: > > > > Beforehand the AR9280 would lock up after 2-3 minutes in monitor mode, > > > and whilst in that mode it'd miss a lot of RX packets. After the > > > initval update, it's been happily receiving in monitor mode for > 30 > > > minutes. I'm quite shocked. :) > > > > I agree. =A0I had several lockups this morning (bb hangs) and the > > wlan0 interface refused to destroy and create after that. =A0Since > > updating, it's been stable for the last hour. > > I think I have you to blame/thank for the AR9280, right? :) You do :) I sent you the AR5B95 AR9281 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: IDE DVD playback on 5.1-CURRENT
Adam K Kirchhoff wrote: > > I've asked this same question on freebsd-questions an on #freebsd > (freenode), but haven't gotten any answer, so I thought I'd ask on here. > > I'm hoping someone can help me out here. > > I recently moved a firewire card and DVD drive that had been in my FreeBSD > box to another computer. I replaced it with an IDE DVD drive. The > probelm is that now I can't get mplayer or vlc to play any DVDs that had > previously worked with the firewire drive. > > I have, of course, made sure that /dev/dvd is a symbolic link to /dev/acd0 > instead of /dev/cd0 (as it used to be). The only difference that I can > think of is that FreeBSD sees the firewire drive as a scsi drive and sees > the ide drive as an ide drive. Have you tried (from mplayer's man page): -dvd-device Override default DVD device name /dev/dvd. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pcic device causes kernel build failure
"M. Warner Losh" wrote: > Don't build pcic with newcard. It is broken, doesn't work and isn't > supported. I have a rewrite in my p4 tree that I'm slugging through, > but pcic is likely to coninue to not compile until that's committed. Will that eventually fix support for the following (dmesg fragment from 4.8-STABLE)?: pcic0: at port 0x3e0 iomem 0xd on isa0 pcic0: Polling mode pccard0: on pcic0 pccard1: on pcic0 I'd like to run CURRENT on this laptop, but this thwarted me last time by revoking my network. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bsd.lib.mk and bsd.own.mk ignore /etc/make.conf(INSTALL)
Hi
Any idea why '-C' is hard coded for bsd.lib.mk and bsd.own.mk? I
thought that the make.conf variable was there to allow or disallow
this. The following comes from bsd.lib.mk:
.if defined(LIB) && !empty(LIB) && !defined(NOINSTALLLIB)
${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \
${_INSTALLFLAGS} lib${LIB}.a ${DESTDIR}${LIBDIR}
.endif
.if !defined(NOPROFILE) && defined(LIB) && !empty(LIB)
${INSTALL} -C -o ${LIBOWN} -g ${LIBGRP} -m ${LIBMODE} \
${_INSTALLFLAGS} lib${LIB}_p.a ${DESTDIR}${LIBDIR}
.endif
Ian
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
Doug Barton wrote: > On Mon, 1 Sep 2003, M. Warner Losh wrote: > > > My tool is initially just a 'delete these files' tool, but now that I > > think about it, it wouldn't be hard to say also 'create these > > symlinks'. The hard part here is generating the 'obsolete' lists. > > I posted one approach to this today... touch a file right before you > start installworld, then consider anything not newer than that file a > candidate for disposal. There is currently something weird going on in > /usr/lib though... a lot of the files don't have newer dates, I haven't > tracked down why yet. That's because bsd.lib.mk and bsd.own.mk hardcode '-C' for install. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
Sheldon Hearn wrote: > On (2003/09/02 09:43), Ian Freislich wrote: > > > > I posted one approach to this today... touch a file right before you > > > start installworld, then consider anything not newer than that file a > > > candidate for disposal. There is currently something weird going on in > > > /usr/lib though... a lot of the files don't have newer dates, I haven't > > > tracked down why yet. > > > > That's because bsd.lib.mk and bsd.own.mk hardcode '-C' for install. > > Which a few of us have complained about and subsequently settled on > local patches for. :-( Which is what I eventually did too after nearly destroying half of /usr/lib because /usr/src/share/examples/etc/make.conf and make.conf(5) *LIE* about (or at the very least misrepresent) what really happens. The explanation 'these files are dependencies' doesn't really explain the need for install -C to me and just makes it harder to find what was installed and what was stale. I propose the following patch to make.conf(5) and something similar to make.conf: Index: make.conf.5 === RCS file: /home/ncvs/src/share/man/man5/make.conf.5,v retrieving revision 1.78 diff -u -d -r1.78 make.conf.5 --- make.conf.5 29 Aug 2003 11:24:53 - 1.78 +++ make.conf.5 2 Sep 2003 08:11:10 - @@ -181,11 +181,15 @@ .It Va INSTALL .Pq Vt str the default install command. -To have commands compared before doing +To have targets compared with the source before doing the install, use .Bd -literal -offset indent INSTALL="install -C" .Ed +Note that some system Makefile includes +hardcode options for +the supplied install command. +Your mileage may vary. .It Va LOCAL_DIRS .Pq Vt str List any directories that should be entered when doing ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bsdlabel wierd.
Hi I was experimenting with growfs yesterday and I noticed this wierd thing crop up in my label. Notice the 'a' partition which I can no longer get rid of and appears automatically. using bsdlabel -e I have to delete this partition if I want to change any of the other partitions (it complains about overlapping partitions otherwise). [brane-dead] / # bsdlabel /dev/ad0s1 # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 20044064 16unused0 0 c: 200440800unused 1024 8192 # "raw" part, don't edit e: 2004408004.2BSD 1024 8192 46248 What am I missing? BTW, growfs barfed too with a 'rdfs: read error'. [brane-dead] /var/log # fdisk /dev/ad0 *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=19885 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=19885 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 0, size 20044080 (9787 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end: cyl 428/ head 15/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Why does bsdlabel autogenerate the 'a' partition?
Hi Why does the bsdlabel program autogenerate the 'a' partition? If I edit the disk label removing all partitions except for 'c' and then save it, a subsequent read of the disk label shows an 'a' partition has been made covering the whole disk. Even if I make another partition using the whole disk, it still makes 'a', which has to be deleted to create other partitions because of the resulting overlap. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sysinstall's fdisk/disklabel should be improved
"David O'Brien" wrote: > On Sun, Oct 26, 2003 at 06:58:52PM +0100, Ulrich Spoerlein wrote: > > First of all, the Partition Editor has the 'A' option to use all of the > > available HDD space. It creates a DOS-compatible slice (starting at > > sector 63 and ending on cylinder boundary). This is completely useless > > on servers and the help menu says that sysinstall will ask if it should > > create a DOS-compatible slice or not. However no such question is ever > > asked. > > It is NOT useless. Why do you think it is? Perhaps you don't relize > that some BIOS's wont boot from a hard disk that isn't partitioned to > agree with the specifications of the PeeCee. If you want to treat your > PC as a Sun, don't -- buy a Sun, FreeBSD runs on that too. Hmmm, not a reason why it's useless, but certainly one case where it just plain doesn't work: I have some SCSI disks which my BIOS refuses to boot unless dangerously dedicated. Any ideas are welcome. They are all the same as this: da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 4340MB (924 512 byte sectors: 64H 32S/T 4340C) Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
interruptNG/ataNG breaks laptop boot.
Hi I have a rather old Dell laptop that I'd like to run current on. A few months back current booted, but the PCIC stuff was broken so I had to back out. I thought I'd give it another try this week. After it probes the disk and GEOM does some stuff it stops responding to keyboard with the harddisk light on solidly. The last output is the following (which can also be found at the end of the verbose boot output): GEOM: create disk ad0 dp=0xc1538170 ad0: ATA-3 disk at ata0-master ad0: 3102MB (6354432 sectors), 6304 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 GEOM: new disk ad0 ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt ad0: WARNING - READ_DMA recovered from missing interrupt Mounting root from ufs:/dev/ad0s1a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> The only thing that can be done at this point is to reboot. At least the loader works with the 4.9 kernel so I can compile new kernels on another machine and copy them accross. Any ideas? Ian OK boot -v SMAP type=01 base= len=000a SMAP type=01 base=0010 len=01f0 Copyright (c) 1992-2003 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 5.1-CURRENT #1: Fri Nov 14 13:36:02 SAST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LAPTOY-CURRENT Preloaded elf kernel "/boot/kernel/kernel" at 0xc06d2000. Calibrating clock(s) ... i8254 clock: 1193227 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 133637357 Hz CPU: Pentium/P54C (133.64-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping = 12 Features=0x1bf real memory = 33554432 (32 MB) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00826000 - 0x01f49fff, 24264704 bytes (5924 pages) avail memory = 27471872 (26 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xbe4e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: Intel Pentium detected, installing workaround for F00F bug random: null: mem: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=00011066) pcibios: BIOS version 2.10 pcib0: at pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1066, dev=0x0001, revid=0x04 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0xa400, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1066, dev=0x8002, revid=0x00 bus=0, slot=6, func=0 class=06-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x000f, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base 3000, size 21, enabled found-> vendor=0x10c8, dev=0x0001, revid=0x01 bus=0, slot=7, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base fe00, size 4, enabled pci_cfgintr: can't route an interrupt to 0:8 INTA found-> vendor=0x1095, dev=0x0643, revid=0x00 bus=0, slot=8, func=0 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=14 isab0: at device 6.0 on pci0 isa0: on isab0 pci0: at device 7.0 (no driver attached) atapci0: port 0xfe00-0xfe0f irq 14 at device 8.0 on pci 0 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 pnpbios: 16 device
acpi_hp fails attach at boot
Hi acpi_hp fails attach at boot, but if I load it manually in multi-user it does attach. I think this is because the acpi_hp module tries to attach very early on before acpi_wmi which it depends on has completed its attach: [mini] ~ # grep ^acpi dmesg acpi0: <061909 RSDT0044> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi_hp0: iomem 0xfed13000-0xfed19fff on acpi0 acpi_hp0: Couldn't find acpi_wmi device acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7f70 (3) failed acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hp0: iomem 0xfed13000-0xfed19fff on acpi0 acpi_hp0: Couldn't find acpi_wmi device acpi_ec0: port 0x62,0x66 on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 acpi_button0: on acpi0 acpi_wmi0: on acpi0 acpi_button1: on acpi0 acpi_tz0: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 If I 'kldload acpi_hp' once the system is booted I get: acpi_wmi0: on acpi0 acpi_hp0: on acpi0 acpi_hp0: HP event GUID detected, installing event handler acpi_hp0: HP CMI GUID detected acpi_wmi obviously waits for the right time before it attempts to probe or attach. How can I make acpi_hp do the same? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Help with igb driver/nics, strange issue.
joe wrote: > I have 3 boxes, each with two nics. One nic for the private network and > one for the public network. > The private network is all on the same vlan. All 6 nics are on the same > switch. All connections are 1000tx Full Duplex. > > I will call the servers Box A, Box B, and Box C. > > When i FTP data between Box A & B i get abou 25MB/sec. > When i FTP data from Box C to Box A or B, i get about 20MB/sec. > When i FTP data from Box A to C i get 10MB/sec > When i FTP data from Box B to C i get 200KB/sec... > > Can anyone suggest why i might only be getting 200KB when transfering > data from Box B to C but not when transferring data from Box A to C? Is the hardware exactly the same on all 3 hosts? From your enumeration it looks like there's something special about box C. How busy are the disks? One of the problems with FTP, at least the last time I tried to use it for benchmarking was that it used tiny, tiny transfers to and from disk. Strangely scp did better even with the crypto overhead. Have you tried using netperf to test the network performance? Have you checked your cables? I've seen all sorts of wierd problems caused by cables. netstat -ni should give an idea of transmission problems. If the switch is a managed switch, you can also check its interface counters. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
joe wrote: > I have just tried your suggeston and it has no effect for me ;( Do you have another brand of NIC that you can try? At least that will isolate whether it's igb(4) or something else. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: igb broken? Unexplained weirdness with intel 82576 nics on a supermicro board.
joe wrote: > On 05/08/2010 06:55 AM, Ian FREISLICH wrote: > > joe wrote: > >> I have just tried your suggeston and it has no effect for me ;( > > > > Do you have another brand of NIC that you can try? At least that > > will isolate whether it's igb(4) or something else. > > I will grab a new nic today and try...my options are limited though. > Here are the nics i can get my hands on > > TP-LINK TL-TG3468, 10/100/1000Mbps PCIe Adapter (supported by fbsd?) Based on the RTL8168B chip. Should be supported by the re(4) driver. > Intel (EXPI9301CT) Gigabit CT Desktop Adapter (yet another intel nic) i82574L chip. Should be supported by the em(4) driver. I have had good performance in the past with this driver and less than satisfactory performance with the igb(4) driver. That may not be your problem though. Before you go out and buy, have a look at the amount of interrupt time your slow machine spends in 'top' or 'systat -vm'. systat will also show the interrupt rate for each driver, perhaps it's not doing interrupt moderation properly. This will manifest as more than about a 1000 per second. There are loader tunables for the driver to increase the number of transfer descriptors and to tune interrupt moderation. You could try running trafshow (port) on the interface while performing the transfer. Perhaps promiscuous mode will turn off some hardware feature that will improve things. It may however break hardware vlanning as it does on my 82575GB 4 port igb card. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
Weongyo Jeong wrote: > > Do you want me to test anything else ? > > OK. The patch is ready to test. Could you please test it with attached > patch? No panic this time. I also don't get these messages any more: May 10 23:25:36 mini kernel: bwn0: unsupported rate 0 May 10 23:26:13 mini last message repeated 2 times May 10 23:28:29 mini last message repeated 320 times May 10 23:28:32 mini last message repeated 61 times May 10 23:29:42 mini shutdown: reboot by ianf: It still doesn't associate with my AP until I destroy the wlan interface and create it again: wlan0: Ethernet address: 00:26:5e:57:23:33 bwn0: firmware version (rev 478 patch 104 date 0x8701 time 0x657) bwn0: need multicast update callback bwn0: RX decryption attempted (old 0 keyidx 0x1) bwn0: need multicast update callback bwn0: need multicast update callback and then I get lots of these but no where near the rate of the'unsupported rate' messages: May 10 23:31:39 mini kernel: bwn0: RX decryption attempted (old 0 keyidx 0x1) May 10 23:32:10 mini last message repeated 13 times May 10 23:34:09 mini last message repeated 34 times Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
Ian FREISLICH wrote: > Weongyo Jeong wrote: > > > Do you want me to test anything else ? > > > > OK. The patch is ready to test. Could you please test it with attached > > patch? > > No panic this time. I also don't get these messages any more: > > May 10 23:25:36 mini kernel: bwn0: unsupported rate 0 > May 10 23:26:13 mini last message repeated 2 times > May 10 23:28:29 mini last message repeated 320 times > May 10 23:28:32 mini last message repeated 61 times > May 10 23:29:42 mini shutdown: reboot by ianf: > > It still doesn't associate with my AP until I destroy the wlan > interface and create it again: But, after about 12 hours it reduced the rate to 36mbit/s OFDM with large amounts of time either not transmitting or not recieving - 86% packet loss over 5 minutes. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
Buganini wrote: > Hi, with yesterday's CURRENT my bwn works partially. > > this is my hardware > siba_b...@pci0:4:0:0: class=0x028000 card=0x04b514e4 chip=0x431514e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)' > class = network > > it works with WPA ap without destroy/re-create wlan0 > , but it's unstable, at the first time it works, it goes forth and > back between "associated" and "no carrier", > the other times it stay associated but network is down. > and this usually followed by system freeze if I `/etc/rc.d/netif restart` > later. > > and it never get associated with a open ap. I'm seeing something similar with my hardware with recent current. It associates but I get massive packet loss to my router over the wireless link: --- 10.0.2.1 ping statistics --- 425 packets transmitted, 195 packets received, 54.1% packet loss round-trip min/avg/max/stddev = 1.460/2.894/86.417/8.110 ms siba_b...@pci0:1:0:0: class=0x028000 card=0x1508103c chip=0x431514e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom Wireless b/g (BCM4315/BCM22062000)' class = network cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 09[58] = vendor (length 120) cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) Current of May 15 works reliably. I'll try to search for the offending commit. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
problem with mfiutil
Hi I'm unable to make a raid10 on my servers with 6 disks in each stripe. I tried a few ways: ~ # mfiutil -u1 create raid10 -s1M e1:s0,e1:s1,e1:s2,e1:s3,e1:s4,e1:s5 e1:s6,e1:s7,e1:s8,e1:s9,e1:s10,e1:s11 mfiutil: Command failed: Invalid parameter mfiutil: Failed to add volume: Input/output error ~ # mfiutil -u1 create raid10 -s1M 19,29,18,26,22,20 31,30,21,27,28,32 mfiutil: Command failed: Invalid parameter mfiutil: Failed to add volume: Input/output error It does however work with 2 disks in each stripe: ~ # mfiutil -u1 create raid10 -s1M 19,29 31,30 any ideas? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem with mfiutil
John Baldwin wrote: > On Friday, August 06, 2010 7:32:00 am Ian FREISLICH wrote: > > Hi > > > > I'm unable to make a raid10 on my servers with 6 disks in each > > stripe. I tried a few ways: > > > > ~ # mfiutil -u1 create raid10 -s1M e1:s0,e1:s1,e1:s2,e1:s3,e1:s4,e1:s5 > e1:s6,e1:s7,e1:s8,e1:s9,e1:s10,e1:s11 > > mfiutil: Command failed: Invalid parameter > > mfiutil: Failed to add volume: Input/output error > > > > ~ # mfiutil -u1 create raid10 -s1M 19,29,18,26,22,20 31,30,21,27,28,32 > > mfiutil: Command failed: Invalid parameter > > mfiutil: Failed to add volume: Input/output error > > > > It does however work with 2 disks in each stripe: > > ~ # mfiutil -u1 create raid10 -s1M 19,29 31,30 > > > > any ideas? > > Yes, you have it inverted. You are creating a stripe across a bunch of > RAID-1's and you need to list all the RAID-1's, so something like this: > > mfiutil -u 1 create raid10 -s 1M 19,31 29,39 18,21 26,27 22,28 20,32 Hmm. I'll give that a try, but it's not the way the controler configured it fyrom the BIOS utility. It was definitely a mirror of 2 6 disk stripes. The controller is a Perc 6/E. My playing has now left: [nagios06.jnb1] ~ # mfiutil -u1 show volumes mfi1 Volumes: Id SizeLevel Stripe State Cache Name mfid2 ( 419G) RAID-1 1M OPTIMAL Enabled 0 ( 837G) RAID-10 1M OPTIMAL Writes And I can't delete the '0' volume. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem with mfiutil
Gary Palmer wrote: > On Fri, Aug 06, 2010 at 06:58:29PM +0200, Ian FREISLICH wrote: > > John Baldwin wrote: > > > On Friday, August 06, 2010 7:32:00 am Ian FREISLICH wrote: > > > > Hi > > > > > > > > I'm unable to make a raid10 on my servers with 6 disks in each > > > > stripe. I tried a few ways: > > > > > > > > ~ # mfiutil -u1 create raid10 -s1M e1:s0,e1:s1,e1:s2,e1:s3,e1:s4,e1:s5 > > > e1:s6,e1:s7,e1:s8,e1:s9,e1:s10,e1:s11 > > > > mfiutil: Command failed: Invalid parameter > > > > mfiutil: Failed to add volume: Input/output error > > > > > > > > ~ # mfiutil -u1 create raid10 -s1M 19,29,18,26,22,20 31,30,21,27,28,32 > > > > mfiutil: Command failed: Invalid parameter > > > > mfiutil: Failed to add volume: Input/output error > > > > > > > > It does however work with 2 disks in each stripe: > > > > ~ # mfiutil -u1 create raid10 -s1M 19,29 31,30 > > > > > > > > any ideas? > > > > > > Yes, you have it inverted. You are creating a stripe across a bunch of > > > RAID-1's and you need to list all the RAID-1's, so something like this: > > > > > > mfiutil -u 1 create raid10 -s 1M 19,31 29,39 18,21 26,27 22,28 20,32 > > > > Hmm. I'll give that a try, but it's not the way the controler > > configured it fyrom the BIOS utility. It was definitely a mirror > > of 2 6 disk stripes. The controller is a Perc 6/E. > > What you described is RAID 0+1, not RAID 10. Typically in RAID 0+1 you > make two stripes, each with half the disks, and then mirror them. RAID > 10 you make lots of mirrored drive pairs and then stripe across all the > mirrors. RAID 10 has higher redundancy and lower rebuild times than 0+1 Understood and I'm not saying it isn't, it's just what the controller reported as its config which led me to what I originally posted. I managed to get the controller to delete the volume it showed wierdly by adding another volume and then deleting the two. I then created the RAID10. I'd love to know what my colleague did to get the previous config because it's apparently not supported by this controller. This is what it looked like before: mfi1 Configuration: 7 arrays, 2 volumes, 1 spares array 0 of 2 drives: drive 23 ( 419G) ONLINE SAS enclosure 1, slot 14 drive 24 ( 419G) ONLINE SAS enclosure 1, slot 13 array 1 of 6 drives: drive 19 ( 419G) ONLINE SAS enclosure 1, slot 0 drive 31 ( 419G) ONLINE SAS enclosure 1, slot 6 drive 18 ( 419G) ONLINE SAS enclosure 1, slot 2 drive 26 ( 419G) ONLINE SAS enclosure 1, slot 3 drive 22 ( 419G) ONLINE SAS enclosure 1, slot 4 drive 20 ( 419G) ONLINE SAS enclosure 1, slot 5 array 2 of 6 drives: drive 29 ( 419G) ONLINE SAS enclosure 1, slot 1 drive 30 ( 419G) ONLINE SAS enclosure 1, slot 7 drive 21 ( 419G) ONLINE SAS enclosure 1, slot 8 drive 27 ( 419G) ONLINE SAS enclosure 1, slot 9 drive 28 ( 419G) ONLINE SAS enclosure 1, slot 10 drive 32 ( 419G) ONLINE SAS enclosure 1, slot 11 volume mfid2 (419G) RAID-1 1M OPTIMAL spans: array 0 volume mfid1 (2512G) RAID-10 1M OPTIMAL spans: array 1 array 2 global spare 25 ( 419G) HOT SPARE SAS enclosure 1, slot 12 This is what the config looks like now: mfi1 Configuration: 7 arrays, 2 volumes, 1 spares array 0 of 2 drives: drive 23 ( 419G) ONLINE SAS enclosure 1, slot 14 drive 24 ( 419G) ONLINE SAS enclosure 1, slot 13 array 1 of 2 drives: drive 19 ( 419G) ONLINE SAS enclosure 1, slot 0 drive 31 ( 419G) ONLINE SAS enclosure 1, slot 6 array 2 of 2 drives: drive 29 ( 419G) ONLINE SAS enclosure 1, slot 1 drive 30 ( 419G) ONLINE SAS enclosure 1, slot 7 array 3 of 2 drives: drive 18 ( 419G) ONLINE SAS enclosure 1, slot 2 drive 21 ( 419G) ONLINE SAS enclosure 1, slot 8 array 4 of 2 drives: drive 26 ( 419G) ONLINE SAS enclosure 1, slot 3 drive 27 ( 419G) ONLINE SAS enclosure 1, slot 9 array 5 of 2 drives: drive 22 ( 419G) ONLINE SAS enclosure 1, slot 4 drive 28 ( 419G) ONLINE SAS enclosure 1, slot 10 array 6 of 2 drives: drive 20 ( 419G) ONLINE SAS drive 32 ( 419G) ONLINE SAS enclosure 1, slot 11 volume mfid2 (419G) RAID-1 1M OPTIMAL spans: array 0 volume mfid1 (2512G) RAID-10 1M OPTIMAL spans: array 1 array 2 array 3 array 4 array 5 array 6 global spare 25 ( 419G) HOT SPARE SAS enclosure 1, slot 12 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New Kernel Breaks IPFW
"Daniel C. Sobral" wrote: > John Stockdale wrote: > > Hey everyone, > > > > I just cvsup'd my src today and was going to buildworld later tonight > > but when I installed the newly built kernel with IPFIREWALL etc. and > > rebooted, ipfw fell over, specifically, even after ipfw firewall enable, > > an ipfw show resulted in a core dump. If its useful, I can post the ipfw > > core dump. > > > > Any ideas why this is? > > Probably because the ABI between ipfw(8) and it's kernel counterpart has > changed. Since you failed to follow the safe path of upgrade > (mergemaster -p, builworld, buildkernel, installkernel, reboot -s (fall > back in case of problems), mount fs and installkernel, mergemaster), > this sort of things can happen. Alas make buildworld fails for the past few days: ===> usr.sbin/config In file included from config.c:1: /usr/include/stdlib.h:102: conflicting types for `restrict' /usr/include/stdlib.h:102: previous declaration of `restrict' /usr/include/stdlib.h:102: warning: redundant redeclaration of `restrict' in same scope /usr/include/stdlib.h:102: warning: previous declaration of `restrict' /usr/include/stdlib.h:103: conflicting types for `restrict' (and also stdio.h, string.h, sys/types.h, select.h) Someone posted a link to the failure that I get, so I'll crib: http://www.0xfce3.net/error.txt > Granted, that rather laborious process is usually unnecessary. I, > myself, often use only buildworld, kernel, installworld, mergemaster and > then reboot. And, of course, I'm fully prepared to take Murphy's Revenge > upon my shoulder if these simple steps fail to yield a working system (a > broken kernel, for instance, with a new world incompatible with the > previous kernel). > > Short term, cd /usr/src/sbin/ipfw; make depend && make all install ought > to fix it. I tried that as well, but the new binary also dumps core, but works well with previous versions of the firewall. Even back as far as my kernel.working from May 7 2003. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New Kernel Breaks IPFW
Terry Lambert wrote: > Apparently, someone hosed the compiler flags. Looking at your > cribbed link: > > > Someone posted a link to the failure that I get, so I'll crib: > > http://www.0xfce3.net/error.txt > > We see: > > cc -O -pipe -std=iso9899:1999 -I/usr/obj/usr/src/i386/legacy/usr/include > -static -L/usr/obj/usr/src/i386/legacy/usr/lib -o xinstall xinstall.o -legacy > > Works. > > cc -O -pipe -I. -I/usr/src/usr.sbin/config -W -Wall -ansi -pedantic > -Wbad-function-cast -Wcast-align -Wcast-qual -Wchar-subscripts -Winline > -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls > -Wshadow -Wstrict-prototypes -Wwrite-strings -std=iso9899:1999 > -I/usr/obj/usr/src/i386/legacy/usr/include -c config.c Hmmm, BDEFLAGS. config.c appears to compile without them. > > > Short term, cd /usr/src/sbin/ipfw; make depend && make all install ought > > > to fix it. > > > > I tried that as well, but the new binary also dumps core, but works > > well with previous versions of the firewall. Even back as far as > > my kernel.working from May 7 2003. > > Bogus header files; specifically, . Because you > can't build world, you are compiling the ipfw program with the old > system include files instead of the new ones. You may also be > missing a cvs update on the ipfw sources themselves (specifically, > ipfw2.c). No, it did compile ipfw2.c (r1.24). I also installed all new includes before I compiled ipfw and re-worlding to no avail. I figured an old kernel with a working firewall was better than a new kernel with no firewall. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: New Kernel Breaks IPFW
Andre Guibert de Bruet wrote: > Ian, > > The new ipfw binary will work with an up-to-date kernel. What you need to > do is boot this new kernel and only then try out the new ipfw binary. That doesn't really explain why the new ipfw binary core dumped with the new kernel, but worked fine with old kernels. Now that I've removed BDECFLAGS, it seems that my buildworld will succeed and whatever it was that was broken that ipfw linked in (statically) will hopefully be fixed and all will be good in my land of -CURRENT, for the moment that is. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ULE crash
Hi
About 4.5 minutes after rebooting with a SCHED_ULE kernel (I give
ULE a go every few months), top started looking really wierd (the
CPU % just kept on accumulating for each process). Before dnetc
started, httpd showed 17% CPU, but the system was supposedly 100%
idle at the time according to top. Then dnetc started and things
got wierd.
last pid: 607; load averages: 1.83, 0.63, 0.25up 0+00:04:23 16:00:48
35 processes: 3 running, 32 sleeping
CPU states: 0.0% user, 99.0% nice, 0.6% system, 0.4% interrupt, 0.0% idle
Mem: 20M Active, 14M Inact, 19M Wired, 20K Cache, 25M Buf, 130M Free
Swap: 512M Total, 512M Free
PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND
603 ianf 139 20 1072K 880K RUN0 0:39 105.47% 105.47% dnetc
575 ianf 139 20 1072K 880K CPU1 1 1:15 102.34% 102.34% dnetc
505 root 760 7208K 5420K select 0 0:01 17.97% 17.97% httpd
375 root40 1276K 948K accept 0 0:00 9.38% 9.38% nfsd
526 nobody 760 9280K 8564K select 1 0:04 5.47% 5.47% squid
607 ianf 760 2196K 1444K CPU0 0 0:00 2.34% 2.34% top
Then it froze. When I got home I found that it had at least dumped
vmcore.24. I'll keep it around for a while and perform any inspections
people want me to. This was with sources updated at 13h30 GMT today.
panic: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 0100
fault virtual address = 0x38
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01e094d
stack pointer = 0x10:0xce772be4
frame pointer = 0x10:0xce772bf4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 603 (dnetc)
trap number = 12
panic: page fault
cpuid = 1; lapic.id = 0100
Stack backtrace:
boot() called on cpu#1
syncing disks, buffers remaining... panic: absolutely cannot call smp_ipi_shootdown
with interrupts already disabled
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
Uptime: 4m15s
Dumping 191 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176
---
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:240
#1 0xc01cbe7f in boot (howto=260) at ../../../kern/kern_shutdown.c:372
#2 0xc01cc2b8 in panic () at ../../../kern/kern_shutdown.c:550
#3 0xc02e8f89 in smp_tlb_shootdown (vector=0, addr1=0, addr2=0)
at ../../../i386/i386/mp_machdep.c:2356
#4 0xc02e92a9 in smp_invlpg_range (addr1=0, addr2=0)
at ../../../i386/i386/mp_machdep.c:2488
#5 0xc02eb548 in pmap_invalidate_range (pmap=0xc03996e0, sva=3365310464,
eva=3365314560) at ../../../i386/i386/pmap.c:721
#6 0xc02eb83d in pmap_qenter (sva=3365310464, m=0xce772884, count=0)
at ../../../i386/i386/pmap.c:948
#7 0xc0218a31 in vm_hold_load_pages (bp=0xc76039a0, from=0, to=3365318656)
at ../../../kern/vfs_bio.c:3574
#8 0xc0216f5a in allocbuf (bp=0xc76039a0, size=8192)
at ../../../kern/vfs_bio.c:2752
#9 0xc0216cee in geteblk (size=8192) at ../../../kern/vfs_bio.c:2634
#10 0xc0213980 in bwrite (bp=0xc75b65d8) at ../../../kern/vfs_bio.c:818
#11 0xc02142dc in bawrite (bp=0x0) at ../../../kern/vfs_bio.c:1153
#12 0xc021d89a in vop_stdfsync (ap=0xce772a14)
at ../../../kern/vfs_default.c:742
#13 0xc0193570 in spec_fsync (ap=0xce772a14)
at ../../../fs/specfs/spec_vnops.c:417
#14 0xc0192a38 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:122
#15 0xc0294c62 in ffs_sync (mp=0xc3950a00, waitfor=2, cred=0xc0d06e80,
td=0xc03702a0) at vnode_if.h:624
#16 0xc022b15b in sync (td=0xc03702a0, uap=0x0)
at ../../../kern/vfs_syscalls.c:142
#17 0xc01cb9a1 in boot (howto=256) at ../../../kern/kern_shutdown.c:281
#18 0xc01cc2b8 in panic () at ../../../kern/kern_shutdown.c:550
#19 0xc02f0da2 in trap_fatal (frame=0xce772ba4, eva=0)
at ../../../i386/i386/trap.c:836
#20 0xc02f0333 in trap (frame=
{tf_fs = -1060044776, tf_es = -831062000, tf_ds = -1071775728, tf_edi =
-1014422336, tf_esi = -1070107520, tf_ebp = -831050764, tf_isp = -831050800, tf_ebx =
0, tf_edx = 0, tf_ecx = -1059988168, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip =
-1071773363, tf_cs = 8, tf_eflags = 66194, tf_esp = -1070107520, tf_ss = 0}) at
../../../i386/i386/trap.c:256
#21 0xc02d8eb8 in calltrap () at {standard input}:97
#22 0xc01e188b in sched_choose () at ../../../kern/sched_ule.c:1161
#23 0xc01d25e6 in choosethread () at ../../../kern/kern_switch.c:140
#24 0xc01d422f in mi_switch () at ../../../kern/kern_synch.c:525
#25 0xc01c1db6 in _mtx_lock_sleep (m=0xc0374a40, opts=0, file=0x0, line=0)
at ../../../kern/kern_mutex.c:636
#26 0xc01ca585 in getrusage (td=0x0, uap=0xce772d10)
at ../../../kern/kern_resource.c:773
#27 0xc02f10fc in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi
Re: ULE crash
Jeff Roberson wrote: > On Wed, 25 Jun 2003, Ian Freislich wrote: > > > Hi > > > > About 4.5 minutes after rebooting with a SCHED_ULE kernel (I give > > ULE a go every few months), top started looking really wierd (the > > CPU % just kept on accumulating for each process). Before dnetc > > started, httpd showed 17% CPU, but the system was supposedly 100% > > idle at the time according to top. Then dnetc started and things > > got wierd. > > There is some bug that is preventing sleeping processes from loosing old > cpu usage. I'm looking into that. Can you tell me what version of the > sched_ule.c file you have? This looks like an old panic. $FreeBSD: src/sys/kern/sched_ule.c,v 1.46 2003/06/21 02:31:49 jeff Exp $ Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE SMP fixed.
Jeff Roberson wrote: > Squashed the bug that was causing panics with nice processes on SMP ULE. That is really good news. I will give it a try later today and let you know if I still get panics with ULE enabled. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE SMP fixed.
Ian Freislich wrote: > Jeff Roberson wrote: > > Squashed the bug that was causing panics with nice processes on SMP ULE. > > That is really good news. I will give it a try later today and let > you know if I still get panics with ULE enabled. Well, the uptime says it all: no panics yet which is very nice. Thank-you. It seems that there is still a problem with the CPU accounting (which is certainly not a problem far less severe than panics) last pid: 906; load averages: 2.61, 2.50, 2.41up 0+01:21:16 14:29:36 38 processes: 4 running, 34 sleeping CPU states: 0.0% user, 99.8% nice, 0.0% system, 0.2% interrupt, 0.0% idle Mem: 21M Active, 15M Inact, 22M Wired, 4K Cache, 28M Buf, 127M Free Swap: 512M Total, 512M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 580 ianf 139 20 1072K 880K RUN0 78:46 105.47% 105.47% dnetc 574 ianf 139 20 1072K 880K CPU1 1 79:21 100.78% 100.78% dnetc 451 root 1140 3468K 2564K select 1 0:02 13.28% 13.28% sshd 372 root40 1296K 976K accept 1 0:00 6.25% 6.25% nfsd 906 root 760 2220K 1476K CPU0 0 0:00 2.34% 2.34% top 899 ianf80 1632K 1340K wait 0 0:00 0.78% 0.78% su Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pgsql logged in on console - su/PAM problem?
Larry Rosenman wrote: > > > --On Tuesday, July 08, 2003 13:58:19 +0200 Lukas Ertl <[EMAIL PROTECTED]> > wrote: > > > Hi, > > > > can anyone explain why the pgsql user is logged in on console nowadays? > I'm seeing the same thing, and am also interested in making it stop. It's got tomething to do with the 'su - pgsql -c ...'. I've been able to reproduce this with an arbitrary user by doing the following, but haven't debugged further: ne-dead] ~ # w 11:34AM up 22:26, 2 users, load averages: 2.46, 2.45, 2.44 USER TTY FROM LOGIN@ IDLE WHAT pgsqlconsole -Tue01PM 22:25 - ianf p0 copernicus.so.cp 11:34AM - w [brane-dead] ~ # su - games Last login: Wed Jul 9 11:33:30 on ttyp0 This account is currently not available. [brane-dead] ~ # w 11:34AM up 22:26, 2 users, load averages: 2.55, 2.47, 2.45 USER TTY FROM LOGIN@ IDLE WHAT pgsqlconsole -Tue01PM 22:25 - gamesp0 -11:34AM - w [brane-dead] ~ # exit exit [brane-dead] ~ $ w 11:34AM up 22:26, 2 users, load averages: 2.50, 2.46, 2.45 USER TTY FROM LOGIN@ IDLE WHAT pgsqlconsole -Tue01PM 22:25 - gamesp0 -11:34AM - w Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Making a disk bootable...
Hi This might sound like a really simple question, but what used to work no longer does. How do you partition, label and make a disk bootable? I've used fdisk to create one slice (da0s1). I then used bsdlabel to make make the partitions a, b, e and f. Then to put the boot block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' it trashes the label. Then I copy all my filesystems off the IDE drive I'm trying to rid myself of onto the SCSI disk. When I tell the BIOS to boot off SCSI, it complains 'Missing Operating System'. So I try to dd the first 512 bytes of ad0 onto da0. The BIOS now doesn't complain about a missing operating system, it just hangs and the label on da0 is trashed. So, after about 7 cycles of fdisk, label, newfs, dump, restore, boot SCSI die 'Missing Operating System', boot IDE I give up and try to use sysinstall compiled on July 9 from sources of the same thinking 'surely the installer must be able to make a disk bootable'. It can't either. BTW, it doesn't even make the filesystems when you 'w'rite the changes in the label editor, even though it say's it's makeing the filesystems. So for the moment, I have to keep the IDE disk just for the MBR and type '1:da(0,a)/boot/loader' which is a bit inconvenient. Does anyone have any suggestions short of putting the disks I want labeled in a -STABLE box (which will be a major PITA since my -STABLE box doesn't have SCSI and the controler is on-board on my -CURRENT box)? Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Making a disk bootable...
Peter McGarvey wrote: > * Ian Freislich <[EMAIL PROTECTED]> [2003-07-14 13:58:39 BST]: > > Hi > > > > This might sound like a really simple question, but what used to > > work no longer does. How do you partition, label and make a disk > > bootable? > > And this may sound like a really stupid answer, but have you considered > using /stand/sysinstall? Yes. See paragraph 4. Aside, I'd like to be able to do this from the command line anyway. > > > I've used fdisk to create one slice (da0s1). I then used bsdlabel > > to make make the partitions a, b, e and f. Then to put the boot > > block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' > > it trashes the label. Then I copy all my filesystems off the IDE > > drive I'm trying to rid myself of onto the SCSI disk. When I tell > > the BIOS to boot off SCSI, it complains 'Missing Operating System'. > > > > So I try to dd the first 512 bytes of ad0 onto da0. The BIOS now > > doesn't complain about a missing operating system, it just hangs > > and the label on da0 is trashed. > > > > So, after about 7 cycles of fdisk, label, newfs, dump, restore, > # boot SCSI die 'Missing Operating System', boot IDE I give up and > # try to use sysinstall compiled on July 9 from sources of the same > # thinking 'surely the installer must be able to make a disk bootable'. > # It can't either. BTW, it doesn't even make the filesystems when > # you 'w'rite the changes in the label editor, even though it say's > > it's makeing the filesystems. So for the moment, I have to keep > > the IDE disk just for the MBR and type '1:da(0,a)/boot/loader' which > > is a bit inconvenient. > > > > Does anyone have any suggestions short of putting the disks I want > > labeled in a -STABLE box (which will be a major PITA since my -STABLE > > box doesn't have SCSI and the controler is on-board on my -CURRENT > > box)? > > > > Ian > > ___ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > -- > TTFN, FNORD > > Peter McGarvey > Freelance FreeBSD Hacker > (will work for bandwidth) > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Making a disk bootable...
Mark Murray wrote: > Hi Ian! > > Ian Freislich writes: > > I've used fdisk to create one slice (da0s1). I then used bsdlabel > > to make make the partitions a, b, e and f. Then to put the boot > > block on 'disklabel -B /dev/da0s1' - if I 'disklabel -B /dev/da0' > > it trashes the label. Then I copy all my filesystems off the IDE > > drive I'm trying to rid myself of onto the SCSI disk. When I tell > > the BIOS to boot off SCSI, it complains 'Missing Operating System'. > > Then, when you fdisk, make damn sure that the probed geometry is used. > After that, you shouldn't have probelms. If that fixes your problem, > please report it in detail to [EMAIL PROTECTED] so we can get a more > permanent fix. I've just tried this dd'ing /dev/zero over the front of the disk first to no avail (the probed geometry is the geometry that fdisk used anyway). I also tried your much loved ficticious geometry of 255H 64S and that didn't work. It's a RPITA. In the end I dangerously dedicated the disk and that works. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Making a disk bootable...
John-Mark Gurney wrote: > Ian Freislich wrote this message on Mon, Jul 14, 2003 at 18:48 +0200: > > I've just tried this dd'ing /dev/zero over the front of the disk > > first to no avail (the probed geometry is the geometry that fdisk > > used anyway). I also tried your much loved ficticious geometry of > > 255H 64S and that didn't work. It's a RPITA. In the end I dangerously > > dedicated the disk and that works. > > One thing you might of been missing is making sure that the type in > the disklabel was set properly. For scsi, it must be SCSI, and for > IDE it must be IDE or ESDI. I had problems with this too. I think all that stuff is no longer in the disklabel: [brane-dead] / # disklabel /dev/da0s1 # /dev/da0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 26214404.2BSD 1024 8192 32776 b: 1048576 262144 swap c: 9240unused0 0 # "raw" part, don't edit e: 2097152 13107204.2BSD 1024 8192 46248 f: 5481052 34078724.2BSD 1024 8192 46248 Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Process stats wrong under ULE
Kris Kennaway wrote: > I'm seeing the following kind of behaviour under ULE on a UP machine > (kernel updated earlier this evening). Notice that the total CPU% > adds up to way more than 100%; indeed one single process is allegedly > using more than 100% CPU, and (not clear from the top(1) output) the > processes that are sleeping do not have their CPU% updated until the > next time they run. Jeff is aware of this and has said it is on his list of things to fix. Not sure where on his list it is though. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
Hi I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP at line 84. My system is UP so I'm not compiling an SMP kernel. /usr/src/sys/x86/x86/intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? interrupt_sorted = mallocarray(num_io_irqs, sizeof(*interrupt_sorted), ^~~~ interrupt_sources /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources' declared here static struct intsrc **interrupt_sources; ^ /usr/src/sys/x86/x86/intr_machdep.c:176:54: error: use of undeclared identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? interrupt_sorted = mallocarray(num_io_irqs, sizeof(*interrupt_sorted), ^~~~ interrupt_sources /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources' declared here static struct intsrc **interrupt_sources; ^ 2 errors generated. *** Error code 1 Stop. make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/BRANE *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src -- Ian Freislich -- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: intr_machdep.c:176:2: error: use of undeclared identifier 'interrupt_sorted'
I moved the #ifdef down one line and its compiling. Ian -- Ian Freislich On 08/29/2018 07:40 PM, John Baldwin wrote: > On 8/29/18 4:20 PM, Ian FREISLICH wrote: >> Hi >> >> I see the definition of interrupt_sorted is #ifdefed out by #ifdef SMP >> at line 84. My system is UP so I'm not compiling an SMP kernel. >> >> /usr/src/sys/x86/x86/intr_machdep.c:176:2: error: use of undeclared >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? >> interrupt_sorted = mallocarray(num_io_irqs, >> sizeof(*interrupt_sorted), >> ^~~~ >> interrupt_sources >> /usr/src/sys/x86/x86/intr_machdep.c:83:24: note: 'interrupt_sources' >> declared here >> static struct intsrc **interrupt_sources; >> ^ >> /usr/src/sys/x86/x86/intr_machdep.c:176:54: error: use of undeclared >> identifier 'interrupt_sorted'; did you mean 'interrupt_sources'? >> interrupt_sorted = mallocarray(num_io_irqs, >> sizeof(*interrupt_sorted), > Probably just needs #ifdef SMP around the mallocarray(). I'll test locallyon > a UP kernel config. > -- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r277959 breaks X display on IvyBridge mobile GT2 IG
Hi With this, my display blanks and never lights up when X starts. [zen] /usr/src # svn diff -r 277958:277959 Index: sys/dev/drm2/i915/intel_display.c === --- sys/dev/drm2/i915/intel_display.c (revision 277958) +++ sys/dev/drm2/i915/intel_display.c (revision 277959) @@ -6995,7 +6995,7 @@ */ I915_WRITE(BLC_PWM_CPU_CTL2, PWM_ENABLE); I915_WRITE(BLC_PWM_CPU_CTL, 0); - I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE | (1<<30)); + I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE); } vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '3rd Gen Core processor Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP void intel_modeset_init_hw(struct drm_device *dev) Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r277959 breaks X display on IvyBridge mobile GT2 IG
Hi With this commit my display blanks and never lights up when X starts. [zen] /usr/src # svn diff -r 277958:277959 Index: sys/dev/drm2/i915/intel_display.c === --- sys/dev/drm2/i915/intel_display.c (revision 277958) +++ sys/dev/drm2/i915/intel_display.c (revision 277959) @@ -6995,7 +6995,7 @@ */ I915_WRITE(BLC_PWM_CPU_CTL2, PWM_ENABLE); I915_WRITE(BLC_PWM_CPU_CTL, 0); - I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE | (1<<30)); + I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE); } void intel_modeset_init_hw(struct drm_device *dev) vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '3rd Gen Core processor Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r277959 breaks X display on IvyBridge mobile GT2 IG
Adrian Chadd wrote:
> Hi,
>
> There's a "invert backlight" option in i915, try setting it to 1?
This is pretty much all I could find (unless I was looking in the
wrong place). It makes no difference. The backlight appears to
be disabled.
Index: intel_display.c
===
--- intel_display.c (revision 278584)
+++ intel_display.c (working copy)
@@ -6938,6 +6938,9 @@
/* Acer Aspire 5734Z must invert backlight brightness */
{ 0x2a42, 0x1025, 0x0459, quirk_invert_brightness },
+
+ /* Asus Zenbook UX31A must invert backlight brightness */
+ { 0x0166, 0x1043, 0x1517, quirk_invert_brightness },
};
static void intel_init_quirks(struct drm_device *dev)
Resulting log message:
Feb 11 11:55:38 zen kernel: info: [drm] applying inverted panel brightness quirk
The flag removed by r278584 is BLM_PCH_OVERRIDE_ENABLE according
to the Linux driver. I think we're not correctly setting or selecting
the PWM channel for backlight control.
>
> -a
>
>
> On 11 February 2015 at 07:41, Ian FREISLICH wrote:
> > Hi
> >
> > With this commit my display blanks and never lights up when X starts.
> >
> > [zen] /usr/src # svn diff -r 277958:277959
> > Index: sys/dev/drm2/i915/intel_display.c
> > ===
> > --- sys/dev/drm2/i915/intel_display.c (revision 277958)
> > +++ sys/dev/drm2/i915/intel_display.c (revision 277959)
> > @@ -6995,7 +6995,7 @@
> > */
> > I915_WRITE(BLC_PWM_CPU_CTL2, PWM_ENABLE);
> > I915_WRITE(BLC_PWM_CPU_CTL, 0);
> > - I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE | (1<<30));
> > + I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE);
> > }
> >
> > void intel_modeset_init_hw(struct drm_device *dev)
> >
> >
> > vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 rev=
0x09
> > hdr=0x00
> > vendor = 'Intel Corporation'
> > device = '3rd Gen Core processor Graphics Controller'
> > class = display
> > subclass = VGA
> > cap 05[90] = MSI supports 1 message enabled with 1 message
> > cap 01[d0] = powerspec 2 supports D0 D3 current D0
> > cap 13[a4] = PCI Advanced Features: FLR TP
> >
> > Ian
> >
> > --
> > Ian Freislich
> > ___
> > freebsd-current@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
--
Meditating Guru
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r277959 breaks X display on IvyBridge mobile GT2 IG
Ian FREISLICH wrote: > Adrian Chadd wrote: > > Hi, > > > > > There's a "invert backlight" option in i915, try setting it to 1? > > This is pretty much all I could find (unless I was looking in the > wrong place). It makes no difference. The backlight appears to > be disabled. Adrian, do you have any idea how to fix the backlight for my laptop? I ended up reversing out your change r277959 in my local copy to make the backlight work again here. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: wpa_supplicant/hostapd 2.4 import
Rui Paulo wrote:
> Hi,
>
> Please test the new wpa_supplicant/hostapd. Here's the patch against FreeBSD
> HEAD:
>
> https://people.freebsd.org/~rpaulo/wpa-2.4.diff
EAP never actually completes the association. Authentication
completes but the link never actually comes up. This configuration
worked with the previous wpa_supplicant.
Config:
network={
ssid="quasar"
key_mgmt=WPA-EAP
eap=PEAP
identity="zen"
password="x"
priority=8
}
RADIUS log:
Wed Apr 22 12:28:20 2015 : Auth: Login OK: [zen] (from client AP-PRO-1 port 0
cli 00-22-5F-70-A1-DF)
Client log:
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: Trying to associate with
00:27:22:6c:0b:8f (SSID='quasar' freq=2437 MHz)
Apr 22 12:28:20 zen kernel: wlan0: link state changed to UP
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: Associated with
00:27:22:6c:0b:8f
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-STARTED EAP
authentication started
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD
vendor=0 method=4 -> NAK
Apr 22 12:28:20 zen dhclient[2297]: send_packet: No buffer space available
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD
vendor=0 method=25
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-METHOD EAP
vendor 0 method 25 (PEAP) selected
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PEER-CERT
depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich Home Network/OU=Freislich
Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za'
hash=79d3b2233b7c0e261445f3fe488ef259fdab3c2fbe0727043ff47b0f3f3d22a0
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PEER-CERT
depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich Home Network/OU=Freislich
Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za'
hash=79d3b2233b7c0e261445f3fe488ef259fdab3c2fbe0727043ff47b0f3f3d22a0
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-PEER-CERT
depth=0 subject='/C=ZA/ST=Western Cape/L=Cape Town/O=Freislich Home
Network/OU=Freislich
Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za'
hash=ea38723d53e84d2574f9edf105cdb904b773479badfedab1f8b9d1abbab0c12e
Apr 22 12:28:20 zen wpa_supplicant[2191]: EAP-MSCHAPV2: Authentication succeeded
Apr 22 12:28:20 zen wpa_supplicant[2191]: EAP-TLV: TLV Result - Success -
EAP-TLV/Phase2 Completed
Apr 22 12:28:20 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-EAP-SUCCESS EAP
authentication completed successfully
Apr 22 12:28:21 zen kernel: wlan0: link state changed to DOWN
Apr 22 12:28:21 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-DISCONNECTED
bssid=00:27:22:6c:0b:8f reason=0
Apr 22 12:28:24 zen wpa_supplicant[2191]: wlan0: Trying to associate with
00:27:22:6c:0b:8f (SSID='quasar' freq=2437 MHz)
Apr 22 12:28:24 zen wpa_supplicant[2191]: wlan0: Associated with
00:27:22:6c:0b:8f
Apr 22 12:28:24 zen kernel: wlan0: link state changed to UP
Apr 22 12:28:24 zen dhclient[2297]: send_packet: No buffer space available
Apr 22 12:28:29 zen last message repeated 2 times
Apr 22 12:28:34 zen wpa_supplicant[2191]: wlan0: Authentication with
00:27:22:6c:0b:8f timed out.
Apr 22 12:28:34 zen wpa_supplicant[2191]: wlan0: CTRL-EVENT-DISCONNECTED
bssid=00:27:22:6c:0b:8f reason=3 locally_generated=1
Apr 22 12:28:34 zen kernel: wlan0: link state changed to DOWN
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CTF: wpa_supplicant/hostapd 2.4 import
Rui Paulo wrote: > > locally_generated=1 Apr 22 12:28:34 zen kernel: wlan0: link state changed > > to DOWN > > Can you send me the log of the previous wpa_supplicant version? Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: Trying to associate with 06:27:22:6c:0b:8f (SSID='quasar' freq=2437 MHz) Apr 6 18:06:38 zen kernel: wlan0: link state changed to UP Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: Associated with 06:27:22:6c:0b:8f Apr 6 18:06:38 zen dhclient[1758]: send_packet: No buffer space available Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=4 -> NAK Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21 Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich Home Network/OU=Freislich Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za' Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=ZA/ST=Western Cape/O=Freislich Home Network/OU=Freislich Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za' Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=ZA/ST=Western Cape/L=Cape Town/O=Freislich Home Network/OU=Freislich Home/CN=freislich.nom.za/emailAddress=c...@freislich.nom.za' Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: WPA: Key negotiation completed with 06:27:22:6c:0b:8f [PTK=CCMP GTK=CCMP] Apr 6 18:06:38 zen wpa_supplicant[1651]: wlan0: CTRL-EVENT-CONNECTED - Connection to 06:27:22:6c:0b:8f completed [id=7 id_str=] Apr 6 18:06:43 zen dhclient: New IP Address (wlan0): 10.0.0.220 Apr 6 18:06:43 zen dhclient: New Subnet Mask (wlan0): 255.255.255.0 Apr 6 18:06:43 zen dhclient: New Broadcast Address (wlan0): 10.0.0.255 Apr 6 18:06:43 zen dhclient: New Routers (wlan0): 10.0.0.1 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ntpd wierdness.
Hi ntpq/ntpd appear inconsistent since at least r284659, reporting my refclocks as false tick and the other selected for PPS, but not time source: [brane] ~/graphing $ ntpq -c peers remote refid st t when poll reach delay offset jitter == xGPS_ONCORE(0) .GPS.0 l8 16 3770.0000.088 0.003 oGPS_ONCORE(1) .GPS.0 l7 16 3770.0000.087 0.003 +.PPS.1 u 21 64 377 31.6552.514 9.528 *.GPS.1 u5 64 377 31.9132.705 2.684 [brane] ~/graphing $ ntpq -c assoc ind assid status conf reach auth condition last_event cnt === 1 44551 913a yes yes none falseticksys_peer 3 2 44552 973a yes yes none pps.peersys_peer 3 3 44553 963a yes yes none sys.peersys_peer 3 4 44554 9424 yes yes none candidate reachable 2 [brane] ~/graphing $ ntpq -crv associd=0 status=0418 leap_none, sync_uhf_radio, 1 event, no_sys_peer, version="ntpd 4.2.8p2-a (1)", processor="amd64", system="FreeBSD/11.0-CURRENT", leap=00, stratum=1, precision=-20, rootdelay=0.000, rootdisp=1.090, refid=GPS, reftime=d945578a.3989f1fd Mon, Jul 6 2015 21:37:46.224, clock=d9455790.a5ebb2cf Mon, Jul 6 2015 21:37:52.648, peer=44552, tc=4, mintc=3, offset=0.089614, frequency=31.102, sys_jitter=0.002181, clk_jitter=0.001, clk_wander=0.001 The Oncore GPS are slightly wierd in they almost always start 32000ms ahead on the first time read from them after reset and then correct themselves resulting in huge jitter at ntpd start, but then with the previous version, the refclocks were always selected as pps.peer and sys.peer. Now, even though the refclocks have settled down, the peer selection seems a little strange. At least not what I'm used to seeing. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
"broken" symbolic links in /usr/lib
Hi I cannot for the life of me figure out why this is so: As non-root: [zen] /usr/lib $ file libgcc_s.so libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 As root: [zen] /usr/lib # file libgcc_s.so libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 Only on one of my machines, all running CURRENT from within a day. The upshot is that I have to be root in order to link code. Any ideas greatly appreciated. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "broken" symbolic links in /usr/lib
Glen Barber wrote: > On Tue, Jul 28, 2015 at 07:31:56PM +, Glen Barber wrote: > > On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote: > > > Hi > > >=20 > > > I cannot for the life of me figure out why this is so: > > >=20 > > > As non-root: > > > [zen] /usr/lib $ file libgcc_s.so > > > libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 > > >=20 > > > As root: > > > [zen] /usr/lib # file libgcc_s.so=20 > > > libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 > > >=20 > > > Only on one of my machines, all running CURRENT from within a day. > > > The upshot is that I have to be root in order to link code. > > >=20 > > > Any ideas greatly appreciated. > > >=20 > >=20 > > What are the permissions on /lib/libgcc_s.so.1 ? > >=20 > > Probably a better question: What are the permissions on /lib ? Answering both: [zen] /usr/lib # ls -ld /lib drwxr-xr-x 3 root wheel 1536 Jul 28 19:07 /lib [zen] /usr/lib # ls -l /lib/libgcc_s.so.1 -r--r--r-- 1 root wheel 57792 Jul 28 19:07 /lib/libgcc_s.so.1 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "broken" symbolic links in /usr/lib
David Wolfskill wrote:
> My experience with SU+J is limited (and negative -- in large part,
> because I tend heavily on "dump | restore" pipelines to copy file
> systems, some of which are "live" at the time (danger mitigated by -L
> flag for dump).
As an aside, mine has been pretty positive, except for once having
/ moved entirely to /lost+found and encoded as inode numbers. That
might be enough for some.
> If you can take that system down, I suggest:
>
> * Reboot to single-user mode.
>
> * Disable SU journaling ("tunefs -j disable $special")
>
> * fsck -p / (at least; possibly elide the "-p")
>
> * If you want SU+J, re-enable it ("tunefs -j enable $special")
>
> * While theory says "exit" at this point should just continue the
> transition to multi-user mode, I'd be inclined to just reboot & watch it
> to make sure nothing "weird" happens that you don't know about.
>
> * Re-test.
So, a couple of fscks found some problems, but none causing this.
I found the actual problem. The mount point for /usr was mode 700
even though the root of the mounted filesystem on /usr was mode 755.
Did I explain that clearly (quite difficult because two things are
the same thing, although they're apparently not)?
Seems that for some reason, some but not all actions involving the
transition between . and .. on the mount point use either the
permissions of the mount point or the permissions of the directory
mounted on that mount point. In the past, the permissions in the
mounted filesystem have always trumped the mount point, but I have
no idea what the spec says. Is this a bug?
Ian
--
Ian Freislich
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "broken" symbolic links in /usr/lib
Glen Barber wrote: > On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote: > > I found the actual problem. The mount point for /usr was mode 700 > > even though the root of the mounted filesystem on /usr was mode 755. > > Did I explain that clearly (quite difficult because two things are > > the same thing, although they're apparently not)? > > Your explanation makes sense to me. The cause of this, however is > unclear - was this something done locally? This is why I asked about > the permissions of '/lib', but based on what you've explained, even > asking for the permissions of '/usr' would not have led to a clear > answer. I think the cause was when I moved to an SSD in this laptop and created the filesystems on the new disk by hand. > So we're clear, '/usr' (unmounted) is 700, but '/usr' (mounted) is 755? > Or is this not the case? This is exactly the case. What's confusing is the inconsistent use of the '/usr' (unmounted) and '/usr' (mounted) modes depending on circumstance. ie, non-root can cd and ls to '/usr' (mounted), but not '/usr' (unmounted), but can't resolve a relative symlink in that path. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r296548 breaks external DP and HDMI on HD4000
Hi With r296548 on the following hardware: vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '3rd Gen Core processor Graphics Controller' class = display subclass = VGA cap 05[90] = MSI supports 1 message enabled with 1 message cap 01[d0] = powerspec 2 supports D0 D3 current D0 cap 13[a4] = PCI Advanced Features: FLR TP I get the following console messages when X starts and my external monitor (Samsung U28E590) goes into epileptic fit attack mode. [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 [drm:pid0:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [drm:pid0:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck [drm:pid1100:ironlake_check_fdi_lanes] *ERROR* WARN ON: I915_READ(SOUTH_CHICKEN1) & FDI_BC_BIFURCATION_SELECT [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! The good news is that I no longer need the following hack to turn on the back light this laptop's LVDS display: Index: sys/dev/drm2/i915/intel_display.c === --- sys/dev/drm2/i915/intel_display.c (revision 296547) +++ sys/dev/drm2/i915/intel_display.c (working copy) @@ -6960,7 +6960,7 @@ */ I915_WRITE(BLC_PWM_CPU_CTL2, PWM_ENABLE); I915_WRITE(BLC_PWM_CPU_CTL, 0); - I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE); + I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE | (1<<30)); } void intel_modeset_init_hw(struct drm_device *dev) -- Ian Freislich -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r296548 breaks external DP and HDMI on HD4000
Hi, It was running 2560x1440. I'm not sure if the chip can do 4k although tho Xorg probe suggests it might. Maybe the rest of the interface electronics can't support the higher clock rate. r296547 does correctly run the external monitor at 2560x1440. Sadly the monitor is an international flight away from me for the 1.5 months so I can't test anything else until I'm back. Ian On 19 March 2016 01:10:54 Jean-Sébastien Pédron wrote: On 14/03/2016 18:59, Ian FREISLICH wrote: Hi Hi! With r296548 on the following hardware: vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 I get the following console messages when X starts and my external monitor (Samsung U28E590) goes into epileptic fit attack mode. [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 [drm:pid0:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off [drm:pid0:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck [drm:pid1100:ironlake_check_fdi_lanes] *ERROR* WARN ON: I915_READ(SOUTH_CHICKEN1) & FDI_BC_BIFURCATION_SELECT [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! On my Haswell laptop, the external DisplayPort doesn't work either. When using Ultra HD, I get garbage. When using Full HD, the image is correct for a few seconds, then the output connector is disabled (talking about Panel status timeout in dmesg). What resolution do you use with your monitor? If you're using Ultra HD, could you please try Full HD? -- Jean-Sébastien Pédron -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r296548 breaks external DP and HDMI on HD4000
Hi Replying to myself... The monitor works with in 1920x1080. Any higher resolution and the monitor displays rapidly changing random colours filled over the entire screen. I'm currently using r298115 with no improvement on the situation. Ian On 03/14/16 13:59, Ian FREISLICH wrote: > Hi > > With r296548 on the following hardware: > > vgapci0@pci0:0:2:0: class=0x03 card=0x15171043 chip=0x01668086 > rev=0x09 hdr=0x00 > vendor = 'Intel Corporation' > device = '3rd Gen Core processor Graphics Controller' > class = display > subclass = VGA > cap 05[90] = MSI supports 1 message enabled with 1 message > cap 01[d0] = powerspec 2 supports D0 D3 current D0 > cap 13[a4] = PCI Advanced Features: FLR TP > > I get the following console messages when X starts and my external > monitor (Samsung U28E590) goes into epileptic fit attack mode. > > [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 > [drm:pid0:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting > [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off > [drm:pid0:intel_cpt_verify_modeset] *ERROR* mode set failed: pipe 0 stuck > [drm:pid1100:ironlake_check_fdi_lanes] *ERROR* WARN ON: > I915_READ(SOUTH_CHICKEN1) & FDI_BC_BIFURCATION_SELECT > [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail! > [drm:pid1100:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail! > > The good news is that I no longer need the following hack to turn on the > back light this laptop's LVDS display: > > Index: sys/dev/drm2/i915/intel_display.c > === > --- sys/dev/drm2/i915/intel_display.c (revision 296547) > +++ sys/dev/drm2/i915/intel_display.c (working copy) > @@ -6960,7 +6960,7 @@ > */ > I915_WRITE(BLC_PWM_CPU_CTL2, PWM_ENABLE); > I915_WRITE(BLC_PWM_CPU_CTL, 0); > - I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE); > + I915_WRITE(BLC_PWM_PCH_CTL1, PWM_ENABLE | (1<<30)); > } > > void intel_modeset_init_hw(struct drm_device *dev) > -- Ian Freislich (M) +1 404 574 0228 -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r299512 breaks dhclient on some networks
Hi I cannot for the life of me figure out why the change in r299512 breaks DHCP on one network I use but not on another network. The only clue I can find is that the request whose response is ignored has the following client ID: 1:6:0:22:5f:70:a1:df The request whose response is use has this client ID: 1:0:22:5f:70:a1:df Here's a dhcpdump of the request/offer that gets ignored. --- TIME: 2016-05-18 18:46:39.134 IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) OP: 1 (BOOTPREQUEST) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 92a34fc3 SECS: 0 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 0.0.0.0 SIADDR: 0.0.0.0 GIADDR: 0.0.0.0 CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: . OPTION: 53 ( 1) DHCP message type 1 (DHCPDISCOVER) OPTION: 61 ( 8) Client-identifier 01:06:00:22:5f:70:a1:df OPTION: 12 ( 3) Host name zen OPTION: 55 ( 9) Parameter Request List 1 (Subnet mask) 28 (Broadcast address) 2 (Time offset) 121 (Classless Static Route) 3 (Routers) 15 (Domainname) 6 (DNS server) 12 (Host name) 119 (Domain Search) --- TIME: 2016-05-18 18:46:39.134 IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df) OP: 2 (BOOTPREPLY) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 92a34fc3 SECS: 0 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 10.0.0.80 SIADDR: 10.0.0.1 GIADDR: 0.0.0.0 CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: . OPTION: 53 ( 1) DHCP message type 2 (DHCPOFFER) OPTION: 54 ( 4) Server identifier 10.0.0.1 OPTION: 51 ( 4) IP address leasetime 259200 (3d) OPTION: 1 ( 4) Subnet mask 255.255.255.0 OPTION: 3 ( 4) Routers 10.0.0.1 OPTION: 6 ( 4) DNS server10.0.0.1 --- And here's the request/offer that works (with the r299512 backed out) --- TIME: 2016-05-18 18:35:33.817 IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) OP: 1 (BOOTPREQUEST) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 866cfd85 SECS: 4 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 0.0.0.0 SIADDR: 0.0.0.0 GIADDR: 0.0.0.0 CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: . OPTION: 53 ( 1) DHCP message type 3 (DHCPREQUEST) OPTION: 50 ( 4) Request IP address10.0.0.220 OPTION: 61 ( 7) Client-identifier 01:00:22:5f:70:a1:df OPTION: 12 ( 3) Host name zen OPTION: 55 ( 9) Parameter Request List 1 (Subnet mask) 28 (Broadcast address) 2 (Time offset) 121 (Classless Static Route) 3 (Routers) 15 (Domainname) 6 (DNS server) 12 (Host name) 119 (Domain Search) --- TIME: 2016-05-18 18:35:33.817 IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.220 (00:22:5f:70:a1:df) OP: 2 (BOOTPREPLY) HTYPE: 1 (Ethernet) HLEN: 6 HOPS: 0 XID: 866cfd85 SECS: 0 FLAGS: 0 CIADDR: 0.0.0.0 YIADDR: 10.0.0.220 SIADDR: 10.0.0.1 GIADDR: 0.0.0.0 CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 SNAME: . FNAME: . OPTION: 53 ( 1) DHCP message type 5 (DHCPACK) OPTION: 54 ( 4) Server identifier 10.0.0.1 OPTION: 51 ( 4) IP address leasetime 259200 (3d) OPTION: 1 ( 4) Subnet mask 255.255.255.0 OPTION: 3 ( 4) Routers 10.0.0.1 OPTION: 6 ( 4) DNS server10.0.0.1 ------- -- Ian Freislich -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify
Re: r299512 breaks dhclient on some networks
On 05/18/16 19:49, Conrad Meyer wrote: > Hey Ian, > > r299512 incorrectly encoded client identifiers because I misunderstood > the intent of the sizeof()-scaled client_id. I reverted that change > and replaced it with r300174, which I believe fixes the first overrun > more correctly. Just checked and DHCP is working again. > (Coverity may still complain about CID 1305550, but I don't believe > it's valid for 'hlen' to exceed sizeof(hw_addr.haddr).) > > Thanks, > Conrad > > On Wed, May 18, 2016 at 3:49 PM, Ian FREISLICH > wrote: >> Hi >> >> I cannot for the life of me figure out why the change in r299512 breaks >> DHCP on one network I use but not on another network. >> >> The only clue I can find is that the request whose response is ignored >> has the following client ID: >> 1:6:0:22:5f:70:a1:df >> >> The request whose response is use has this client ID: >> 1:0:22:5f:70:a1:df >> >> Here's a dhcpdump of the request/offer that gets ignored. >> >> --- >> >> TIME: 2016-05-18 18:46:39.134 >> IP: 0.0.0.0 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) >> OP: 1 (BOOTPREQUEST) >> HTYPE: 1 (Ethernet) >> HLEN: 6 >> HOPS: 0 >>XID: 92a34fc3 >> SECS: 0 >> FLAGS: 0 >> CIADDR: 0.0.0.0 >> YIADDR: 0.0.0.0 >> SIADDR: 0.0.0.0 >> GIADDR: 0.0.0.0 >> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 >> SNAME: . >> FNAME: . >> OPTION: 53 ( 1) DHCP message type 1 (DHCPDISCOVER) >> OPTION: 61 ( 8) Client-identifier 01:06:00:22:5f:70:a1:df >> OPTION: 12 ( 3) Host name zen >> OPTION: 55 ( 9) Parameter Request List 1 (Subnet mask) >> 28 (Broadcast address) >> 2 (Time offset) >> 121 (Classless Static Route) >> 3 (Routers) >> 15 (Domainname) >> 6 (DNS server) >> 12 (Host name) >> 119 (Domain Search) >> >> --- >> >> TIME: 2016-05-18 18:46:39.134 >> IP: 10.0.0.1 (4c:5e:0c:62:4f:82) > 10.0.0.80 (00:22:5f:70:a1:df) >> OP: 2 (BOOTPREPLY) >> HTYPE: 1 (Ethernet) >> HLEN: 6 >> HOPS: 0 >>XID: 92a34fc3 >> SECS: 0 >> FLAGS: 0 >> CIADDR: 0.0.0.0 >> YIADDR: 10.0.0.80 >> SIADDR: 10.0.0.1 >> GIADDR: 0.0.0.0 >> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 >> SNAME: . >> FNAME: . >> OPTION: 53 ( 1) DHCP message type 2 (DHCPOFFER) >> OPTION: 54 ( 4) Server identifier 10.0.0.1 >> OPTION: 51 ( 4) IP address leasetime 259200 (3d) >> OPTION: 1 ( 4) Subnet mask 255.255.255.0 >> OPTION: 3 ( 4) Routers 10.0.0.1 >> OPTION: 6 ( 4) DNS server10.0.0.1 >> --- >> >> >> And here's the request/offer that works (with the r299512 backed out) >> >> --- >> >> TIME: 2016-05-18 18:35:33.817 >> IP: 10.0.0.220 (00:22:5f:70:a1:df) > 255.255.255.255 (ff:ff:ff:ff:ff:ff) >> OP: 1 (BOOTPREQUEST) >> HTYPE: 1 (Ethernet) >> HLEN: 6 >> HOPS: 0 >>XID: 866cfd85 >> SECS: 4 >> FLAGS: 0 >> CIADDR: 0.0.0.0 >> YIADDR: 0.0.0.0 >> SIADDR: 0.0.0.0 >> GIADDR: 0.0.0.0 >> CHADDR: 00:22:5f:70:a1:df:00:00:00:00:00:00:00:00:00:00 >> SNAME: . >> FNAME: . >> OPTION: 53 ( 1) DHCP message type 3 (DHCPREQUEST) >> OPTION: 50 ( 4) Request IP address10.0.0.220 >> OPTION: 61 ( 7) Client-identifier 01:00:22:5f:70:a1:df >> OPTION: 12 ( 3) Host name zen >> OPTION: 55 ( 9) Parameter Request List 1 (Subnet mask) >> 28 (Broadcast address) >> 2 (Time offset) >> 121 (Classless Static Route) >> 3 (Routers) >>
Re: r299512 breaks dhclient on some networks
On 05/18/16 20:19, Don Lewis wrote > It looks to me like r299512 is changing the format of the client > identifier by inserting the struct hardware hlen field into it. That's > not valid if htype is non-zero the way I interpret RFC 2132. On the > other hand, I would think that the server would interpret the client ID > as an opaque cookie, so I wouldn't think it would make a difference > (other than thinking this is a new client) unless your server is > configured to look for specific client IDs. It's not that the server isn't working. The client is discarding the server's offer for whatever reason. But, r300174 has it working again for me. I can't speak to the correctness of the fix though. Ian -- Ian Freislich -- Cape Augusta Digital Properties, LLC a Cape Augusta Company *Breach of confidentiality & accidental breach of confidentiality * This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
