Re: PING: Someone on the core team. (Modem Problem)
At about the time of 2/13/2007 10:24 PM, M. Warner Losh stated the following: In message: [EMAIL PROTECTED] Daniel Rudy [EMAIL PROTECTED] writes: : At about the time of 2/12/2007 10:49 PM, M. Warner Losh stated the : following: : : sio0: configured irq 19 not in bitmap of probed irqs 0 : : sio0: port may not be enabled : : This may be your problem. sio isn't detecting the interrupts : happening on this card, it seems, from this dmesg. You may need to : use John Baldwin's hacks to force sio to not use fast interrupts. : This makes it possible to share it with non-fast interrupt sources. : Please let me know if you need these patches. : : I'm working on changing the hardware around and moving the modem to a : different PCI slot to see if that makes a difference. The system is : reinstalling right now on the machine (I tried to install Linux but it : failed...miserably). OK. Please let me know if you need any additional help. Are the sis cards add-in cards, or on the motherboard? Warner Changing the slot did help. I moved it from slot 3 to slot 1. But, now it's dropping characters with a port speed of 57600, and I am also getting irq overrun errors from the kernel too now. This is actually much better than I had before. With a port speed of 2400, I do not drop characters. Here's the message that I got: sio4: 2374 more interrupt-level buffer overflows (total 2374) test# vmstat -i interrupt total rate irq1: atkbd0 6 0 irq6: fdc010 0 irq14: ata0 1120 1 irq15: ata1 47 0 irq17: sio4 415 0 irq19: sis0 sis2 970 1 cpu0: timer 1764263 1998 Total1766831 2000 test# From what I can tell, PCI slot 3 and sis0 on the mainboard are both tied to irq 19, which probably was the whole problem. But now I'm having an irq latency problem. This is progressing well though. -- Daniel Rudy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PING: Someone on the core team. (Modem Problem)
At about the time of 2/13/2007 10:24 PM, M. Warner Losh stated the following: In message: [EMAIL PROTECTED] Daniel Rudy [EMAIL PROTECTED] writes: : At about the time of 2/12/2007 10:49 PM, M. Warner Losh stated the : following: : : sio0: configured irq 19 not in bitmap of probed irqs 0 : : sio0: port may not be enabled : : This may be your problem. sio isn't detecting the interrupts : happening on this card, it seems, from this dmesg. You may need to : use John Baldwin's hacks to force sio to not use fast interrupts. : This makes it possible to share it with non-fast interrupt sources. : Please let me know if you need these patches. : : I'm working on changing the hardware around and moving the modem to a : different PCI slot to see if that makes a difference. The system is : reinstalling right now on the machine (I tried to install Linux but it : failed...miserably). OK. Please let me know if you need any additional help. Are the sis cards add-in cards, or on the motherboard? Warner Ok, as someone requested, here is a verbose kernel boot log: Copyright (c) 1992-2007 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Preloaded elf kernel /boot/kernel/kernel at 0xc0b52000. Preloaded elf module /boot/kernel/acpi.ko at 0xc0b52188. MP Configuration Table version 1.4 found at 0xc00f0c00 Table 'FACP' at 0x5ff3040 Table 'APIC' at 0x5ff69c0 MADT: Found table at 0x5ff69c0 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled ACPI APIC Table: AWARD AWRDACPI Calibrating clock(s) ... i8254 clock: 1193299 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1662506544 Hz CPU: AMD Sempron(tm) 2400+ (1662.51-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x681 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc0480800SYSCALL,MP,MMX+,3DNow+,3DNow Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 100597760 (95 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c25000 - 0x05dfefff, 85827584 bytes (20954 pages) avail memory = 88813568 (84 MB) bios32: Found BIOS32 Service Directory header at 0xc00fb010 bios32: Entry = 0xfb490 (c00fb490) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb4e0 pnpbios: Found PnP BIOS data at 0xc00fbe90 pnpbios: Entry = f:bec0 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Routing external 8259A's - intpin 0 ioapic0: intpin 0 - ExtINT (edge, high) ioapic0: intpin 1 - ISA IRQ 1 (edge, high) ioapic0: intpin 2 - ISA IRQ 2 (edge, high) ioapic0: intpin 3 - ISA IRQ 3 (edge, high) ioapic0: intpin 4 - ISA IRQ 4 (edge, high) ioapic0: intpin 5 - ISA IRQ 5 (edge, high) ioapic0: intpin 6 - ISA IRQ 6 (edge, high) ioapic0: intpin 7 - ISA IRQ 7 (edge, high) ioapic0: intpin 8 - ISA IRQ 8 (edge, high) ioapic0: intpin 9 - ISA IRQ 9 (edge, high) ioapic0: intpin 10 - ISA IRQ 10 (edge, high) ioapic0: intpin 11 - ISA IRQ 11 (edge, high) ioapic0: intpin 12 - ISA IRQ 12 (edge, high) ioapic0: intpin 13 - ISA IRQ 13 (edge, high) ioapic0: intpin 14 - ISA IRQ 14 (edge, high) ioapic0: intpin 15 - ISA IRQ 15 (edge, high) ioapic0: intpin 16 - PCI IRQ 16 (level, low) ioapic0: intpin 17 - PCI IRQ 17 (level, low) ioapic0: intpin 18 - PCI IRQ 18 (level, low) ioapic0: intpin 19 - PCI IRQ 19 (level, low) ioapic0: intpin 20 - PCI IRQ 20 (level, low) ioapic0: intpin 21 - PCI IRQ 21 (level, low) ioapic0: intpin 22 - PCI IRQ 22 (level, low) ioapic0: intpin 23 - PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 - intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI - LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high ioapic0 Version 1.4 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00040010 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x err: 0x0001 pcm: 0x0001 wlan: 802.11 Link Layer
sil3124 sata raid ...
Hi, Just wondering if there is any planned support for this card (or similar) danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sil3124 sata raid ...
Danny Braniss wrote: Hi, Just wondering if there is any planned support for this card (or similar) I've added sos@ to Cc list, who may have interest to this as well. Note that developing drivers requires that the developer has his hands on actual hardware and hardware specifications. Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: sil3124 sata raid ...
LI Xin wrote: Danny Braniss wrote: Hi, Just wondering if there is any planned support for this card (or similar) I've added sos@ to Cc list, who may have interest to this as well. Note that developing drivers requires that the developer has his hands on actual hardware and hardware specifications. Exactly, get me the HW on my lab table and I'll do the driver as time/docs permits, its that simple :) -Søren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
The truth about SigEx Ventures and the SigEx Foundry
First of all, I'd like to appologise for the noise and for cross-posting. This is my first and last e-mail on this list. As you may have noticed from the subject of the e-mail, I'm about to speak about the SigEx Ventures company, an organisation that appoints itself as the liaison between strategic investors and young tallented people in ITC. It originates in the US but currently operates in Europe. Specifically in Pau, France. On their website (www.sigex.com, now www.thefoundryschool.tv) they speak fluent Corporatese. I must admit, I'm not a native English speaker, but even so my ear is trained well enough for me to be able to tell spam from ham. They present some glossy products, that nobody ever actually saw working. They're all vaporware. On the same website they speak about fantastic opportunities offered to young talented fellows in the ITC field, in the shape of internship at their fantastic research centre in Pau. Unfortunately, it's all in the demo because the real deal is nothing like it. There's no such thing as opportunity to work with cutting-edge technologies or leading researchers in the branch. It's all smoke and mirrors. As a former intern there, I feel that the truth should be made available, as neither of their statements really hold true. My best bet is that they attract investors and suck up their cash without ever producing anything. I'm gathering all sorts of information, starting with my own experience, on http://sigexfoundry.blogspot.com. Feel free to read more there. Why am I doing this? There is a term for my action, called whistleblowing. I'd like to underline the fact that I'm by no means affected by SigEx's past or current actions, I went there as an intern for merely satisfying my own curiosity about them. But I know that many of the subscribers of this list are scholars, professors, people with strong positions in the branch, most of which can easily pass as models for younger enthusiasts. They're the ones I'd like this mail to reach. It'd be a real pity if more people suffered from SigEx's dubious practices. Once again, here is the link to the blog: http://sigexfoundry.blogspot.com And, once again, sorry for the noise. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Updated Driver for 3945ABG Intel 3945ABG Wireless LAN controller
Michel Talon wrote: For me the driver 0070121-wpi-freebsd.tar.gz as mentioned in the postof Gilbert Cao is the only one that works, and works very well. I am just using it now. My computer is a Sony Vaio VGN C1 in 32 bits mode. I would like to second this. I have tried the 20070125-wpi-freebsd.tar.gz and the 20070131-wpi-freebsd.tar.gz drivers from http://www.clearchain.com/~benjsc/download/, and I get screens full of debug messages [scanning many channels], but the interface always reports 'no carrier'. I am sending this using the 0070121-wpi-freebsd.tar.gz driver. The machine here is a Toshiba Tecra m6-EZ6611, and I am running FreeBSD 6.2-stable [base system updated 17 Jan 2007]. I'm not much of a hacker, but I can test and send results. I appreciate all the work that has been done, and now I can use this work laptop [they said I could load any OS I wanted on it] without an external wireless card. -- jim smith ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 5.5 persistent crashing
Hi,
Im trying to get to the bottom of some issues we have been experiencing
with a server of ours. We have so far tried replacing the memory in the
server and we are still experiencing the crashes.
If anyone has any ideas as to what could be causing this, or possible kgdb
tricks to try.
Server details
* Dual Xeon 3GHz
* 1GB DDR2 400MHz
* 3ware 8006/2LP RAID
* 2x 160GB SATA drives
Uname Output
# uname -a
FreeBSD xxx 5.5-RELEASE-p11 FreeBSD 5.5-RELEASE-p11 #0: Sun Feb 11 17:08:57
GMT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/xxx i386
Kernel Debugger output
# kgdb kernel.debug /usr/crash/vmcore.7
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Cannot access memory at address 0xc0c3c3a1
(kgdb) where
#0 doadump () at pcpu.h:160
#1 0xc04e09f5 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:412
#2 0xc04e0d19 in panic (fmt=0xc0623851 %s) at
/usr/src/sys/kern/kern_shutdown.c:568
#3 0xc0601b14 in trap_fatal (frame=0xe7231740, eva=28) at
/usr/src/sys/i386/i386/trap.c:822
#4 0xc0601853 in trap_pfault (frame=0xe7231740, usermode=0, eva=28) at
/usr/src/sys/i386/i386/trap.c:737
#5 0xc06014ad in trap (frame=
{tf_fs = -1068564456, tf_es = -1067319280, tf_ds = -1068564464, tf_edi
= 4, tf_esi = 0, tf_ebp = -417130596, tf_isp = -417130644, tf_ebx = 131074,
tf_edx = -1013448320, tf_ecx = 0, tf_eax = 4, tf_trapno = 12, tf_err = 2,
tf_eip = -1068229475, tf_cs = 8, tf_eflags = 66118, tf_esp = 7, tf_ss =
-417129328}) at /usr/src/sys/i386/i386/trap.c:427
#6 0xc05ef8aa in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7 0xc04f0018 in MD5Update (context=0x4, input=0x20002 Address 0x20002 out
of bounds, inputLen=3281518976) at /usr/src/sys/kern/md5c.c:172
#8 0xc049fc21 in procfs_doprocfile (td=0xc3980180, p=0xc4951a98,
pn=0xc1fe7c00, sb=0xe72317f0, uio=0x0) at /usr/src/sys/fs/procfs/procfs.c:73
#9 0xc04a3e90 in pfs_readlink (va=0x0) at pcpu.h:157
#10 0xc053cbb8 in kern_readlink (td=0xc3980180, path=0x0,
pathseg=UIO_USERSPACE, buf=0x0, bufseg=UIO_USERSPACE, count=1024) at
vnode_if.h:925
#11 0xc053cade in readlink (td=0xc3980180, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:2197
#12 0xc0601e4f in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135512892, tf_esi =
135663632, tf_ebp = -1077940936, tf_isp = -417129116, tf_ebx = 674101364,
tf_edx = -1077941960, tf_ecx = 0, tf_eax = 58, tf_trapno = 135517392, tf_err
= 2, tf_eip = 672575044, tf_cs = 31, tf_eflags = 647, tf_esp = -1077942020,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1014
#13 0xc05ef8ff in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:201
#14 0x002f in ?? ()
#15 0x002f in ?? ()
#16 0x002f in ?? ()
#17 0x0813c33c in ?? ()
#18 0x08161010 in ?? ()
#19 0xbfbfed38 in ?? ()
#20 0xe7231d64 in ?? ()
#21 0x282df874 in ?? ()
#22 0xbfbfe938 in ?? ()
#23 0x in ?? ()
#24 0x003a in ?? ()
#25 0x0813d4d0 in ?? ()
#26 0x0002 in ?? ()
#27 0x2816ae44 in ?? ()
#28 0x001f in ?? ()
#29 0x0287 in ?? ()
#30 0xbfbfe8fc in ?? ()
#31 0x002f in ?? ()
#32 0x in ?? ()
#33 0x in ?? ()
#34 0x in ?? ()
#35 0x in ?? ()
#36 0x0bf63000 in ?? ()
#37 0xc3984a98 in ?? ()
#38 0xc3980180 in ?? ()
#39 0xe7231600 in ?? ()
#40 0xe72315e8 in ?? ()
#41 0xc1efc780 in ?? ()
#42 0xc04f105f in sched_switch (td=0x8161010, newtd=0x282df874, flags=Cannot
access memory at address 0xbfbfed48
) at /usr/src/sys/kern/sched_4bsd.c:881
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Regards,
Geoff Garside
Open Hosting Ltd
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
portupgrade O(n^m)?
I have 734 ports installed on my laptop right now. I'm pretty sure, at times, I've had over 1000 ports on my laptop. On machine with moderate numbers of ports (most servers seem to have 50 to 200 ports), portupgrade takes a moderate amount of time to start work. On machines like my laptop, portupgrade seems to take much more time to run. I assume it's solving the dependency graph before it decides what to upgrade first, but is this truly a O(n^2) problem? It seems like the implemented algorithm is O(n^2). Dave. -- |David Gilbert, Independent Contractor. | Two things can be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade O(n^m)?
On Wednesday 14 February 2007 12:41, David Gilbert wrote: I have 734 ports installed on my laptop right now. I'm pretty sure, at times, I've had over 1000 ports on my laptop. On machine with moderate numbers of ports (most servers seem to have 50 to 200 ports), portupgrade takes a moderate amount of time to start work. On machines like my laptop, portupgrade seems to take much more time to run. I assume it's solving the dependency graph before it decides what to upgrade first, but is this truly a O(n^2) problem? It seems like the implemented algorithm is O(n^2). Just a me too. I noticed a huge increase in time for portupgrade when I started using the modular Xorg ports tree and upgraded to X.org 7.2RC. The number of installed ports on my machine went from just over 300 to well over 600 as a result of the upgrade. Specifying small numbers of ports (without globbing) to portupgrade doesn't seem to take much more time, but portupgrade -a or anything similar takes forever now. If there is an optimization to be made there it would be good to do it before modular xorg hits the official tree. JN ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade O(n^m)?
On Wed, Feb 14, 2007 at 12:41:33PM -0500, David Gilbert wrote: On machine with moderate numbers of ports (most servers seem to have 50 to 200 ports), portupgrade takes a moderate amount of time to start work. On machines like my laptop, portupgrade seems to take much more time to run. I assume it's solving the dependency graph before it decides what to upgrade first, but is this truly a O(n^2) problem? It seems like the implemented algorithm is O(n^2). Well, the complexity is somewhere in the area of O(nm) with m being small. I strongly suggest some basic bucket hashing if it is not done already. For the pkgsrc bulk build (which has similiar problems) it reduced the time to around 3 minutes to resolve all dependencies (6k packages), initally it was somewhere in the area of 1h. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade O(n^m)?
On 2/14/07, John Nielsen [EMAIL PROTECTED] wrote: On Wednesday 14 February 2007 12:41, David Gilbert wrote: I have 734 ports installed on my laptop right now. I'm pretty sure, at times, I've had over 1000 ports on my laptop. On machine with moderate numbers of ports (most servers seem to have 50 to 200 ports), portupgrade takes a moderate amount of time to start work. On machines like my laptop, portupgrade seems to take much more time to run. I assume it's solving the dependency graph before it decides what to upgrade first, but is this truly a O(n^2) problem? It seems like the implemented algorithm is O(n^2). Just a me too. I noticed a huge increase in time for portupgrade when I started using the modular Xorg ports tree and upgraded to X.org 7.2RC. The number of installed ports on my machine went from just over 300 to well over 600 as a result of the upgrade. Specifying small numbers of ports (without globbing) to portupgrade doesn't seem to take much more time, but portupgrade -a or anything similar takes forever now. If there is an optimization to be made there it would be good to do it before modular xorg hits the official tree. JN I've also had this problem. I have found that if I perform a portsdb -U pkgdb -F every time following a cvsup that portupgrade doesn't try to go through the full ports indexing steps again. It is still slow, and any improvement that can be made should be. It is already a significant enough pain that most ports build in a shorter amount of time than it takes portupgrade to update its database. -- Coleman Kane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade O(n^m)?
[EMAIL PROTECTED]:~ % pkg_info | wc -l -[19:49]- 917 Really portupgrade becomes clearly not so usable for me after I switch to Xorg 7.2RC which install 300 more packages, my workstation is a xSeries 226 with a Xeon 2,8Ghz 1Go DDR2. So I can imagine what it does on a laptop... This issue is not only related to portupgrade, pkg_add a new port takes far too long now... and make index each time I upgrade my ports is awfull too. Someone has to do something (tm) Regards, Le 14 févr. 07 à 19:36, Coleman Kane a écrit : On 2/14/07, John Nielsen [EMAIL PROTECTED] wrote: On Wednesday 14 February 2007 12:41, David Gilbert wrote: I have 734 ports installed on my laptop right now. I'm pretty sure, at times, I've had over 1000 ports on my laptop. On machine with moderate numbers of ports (most servers seem to have 50 to 200 ports), portupgrade takes a moderate amount of time to start work. On machines like my laptop, portupgrade seems to take much more time to run. I assume it's solving the dependency graph before it decides what to upgrade first, but is this truly a O(n^2) problem? It seems like the implemented algorithm is O(n^2). Just a me too. I noticed a huge increase in time for portupgrade when I started using the modular Xorg ports tree and upgraded to X.org 7.2RC. The number of installed ports on my machine went from just over 300 to well over 600 as a result of the upgrade. Specifying small numbers of ports (without globbing) to portupgrade doesn't seem to take much more time, but portupgrade -a or anything similar takes forever now. If there is an optimization to be made there it would be good to do it before modular xorg hits the official tree. JN I've also had this problem. I have found that if I perform a portsdb -U pkgdb -F every time following a cvsup that portupgrade doesn't try to go through the full ports indexing steps again. It is still slow, and any improvement that can be made should be. It is already a significant enough pain that most ports build in a shorter amount of time than it takes portupgrade to update its database. -- Coleman Kane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED] -- Olivier Warin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated Driver for 3945ABG Intel 3945ABG Wireless LAN controller
[EMAIL PROTECTED] schreef: Michel Talon wrote: For me the driver 0070121-wpi-freebsd.tar.gz as mentioned in the postof Gilbert Cao is the only one that works, and works very well. I am just using it now. My computer is a Sony Vaio VGN C1 in 32 bits mode. I would like to second this. I have tried the 20070125-wpi-freebsd.tar.gz and the 20070131-wpi-freebsd.tar.gz drivers from http://www.clearchain.com/~benjsc/download/, and I get screens full of debug messages [scanning many channels], but the interface always reports 'no carrier'. Same here. The 01/31 driver associated once (I think), but mostly just hangs or crashes my laptop. The 01/21 driver seems to work fine (I get 1 LOR). Laptop: Asus A6JE, card-0x10018086 chip=0x42228086 rev=0x02 hdr=0x00 OS : 7.0-CURRENT i386 2007/02/06 LOR : pci4:1:3: reprobing on driver added wpi0: fatal firmware error wpi0: configure command failed wpi0: could not configure device wpi0: link state changed to UP lock order reversal: 1st 0xc724fb50 wpi0 (network driver) @ if_wpi.c:1555 2nd 0xc075560c udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:294 KDB: stack backtrace: db_trace_self_wrapper(c0696cf6,e7984a28,c052d735,c0698dc6,c075560c,...) at db_trace_self_wrapper+0x27 kdb_backtrace(c0698dc6,c075560c,c06987e1,c06987e1,c06a3184,...) at kdb_backtrace+0x2f witness_checkorder(c075560c,9,c06a3184,126,0,...) at witness_checkorder+0x6e4 _mtx_lock_flags(c075560c,0,c06a3184,126,c04fa08a,...) at _mtx_lock_flags+0xb9 udp_input(c6cfce00,14,c4e51000,1,0,...) at udp_input+0x221 ip_input(c6cfce00,c06930ee,c6d1882e,c4e51000,c6d1882e,...) at ip_input+0x67f netisr_dispatch(2,c6cfce00,6,3,0,...) at netisr_dispatch+0x68 ether_demux(c4e51000,c6cfce00,3,0,3,9) at ether_demux+0x2e6 ether_input(c4e51000,c6cfce00,c724fa24,c6cfce00,18,...) at ether_input+0x26f ieee80211_deliver_data(c6cfce00,e7984c2c,6,18,c052cf03,...) at ieee80211_deliver_data+0x80 ieee80211_input(c724f008,c6cfce00,c50f9c00,28,0,...) at ieee80211_input+0xb71 wpi_intr(c724f000,0,c06911b0,2aa,1,...) at wpi_intr+0x6df ithread_execute_handlers(c55da480,c4d75800,c06911b0,30e,c53f21b0,...) at ithread_execute_handlers+0x14c ithread_loop(c6383650,e7984d38,c0690f94,328,c55da480,...) at ithread_loop+0x78 fork_exit(c04e14fc,c6383650,e7984d38) at fork_exit+0xcc fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe7984d6c, ebp = 0 --- Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) It won't fit on the line. -- me, 2001 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.5 persistent crashing
On Wed, Feb 14, 2007 at 04:09:54PM -, Geoff Garside wrote:
Hi,
I?m trying to get to the bottom of some issues we have been experiencing
with a server of ours. We have so far tried replacing the memory in the
server and we are still experiencing the crashes.
If anyone has any ideas as to what could be causing this, or possible kgdb
tricks to try.
Server details
* Dual Xeon 3GHz
* 1GB DDR2 400MHz
* 3ware 8006/2LP RAID
* 2x 160GB SATA drives
Uname Output
# uname -a
FreeBSD xxx 5.5-RELEASE-p11 FreeBSD 5.5-RELEASE-p11 #0: Sun Feb 11 17:08:57
GMT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/xxx i386
Kernel Debugger output
# kgdb kernel.debug /usr/crash/vmcore.7
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Cannot access memory at address 0xc0c3c3a1
(kgdb) where
#0 doadump () at pcpu.h:160
#1 0xc04e09f5 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:412
#2 0xc04e0d19 in panic (fmt=0xc0623851 %s) at
/usr/src/sys/kern/kern_shutdown.c:568
#3 0xc0601b14 in trap_fatal (frame=0xe7231740, eva=28) at
/usr/src/sys/i386/i386/trap.c:822
#4 0xc0601853 in trap_pfault (frame=0xe7231740, usermode=0, eva=28) at
/usr/src/sys/i386/i386/trap.c:737
#5 0xc06014ad in trap (frame=
{tf_fs = -1068564456, tf_es = -1067319280, tf_ds = -1068564464, tf_edi
= 4, tf_esi = 0, tf_ebp = -417130596, tf_isp = -417130644, tf_ebx = 131074,
tf_edx = -1013448320, tf_ecx = 0, tf_eax = 4, tf_trapno = 12, tf_err = 2,
tf_eip = -1068229475, tf_cs = 8, tf_eflags = 66118, tf_esp = 7, tf_ss =
-417129328}) at /usr/src/sys/i386/i386/trap.c:427
#6 0xc05ef8aa in calltrap () at /usr/src/sys/i386/i386/exception.s:140
#7 0xc04f0018 in MD5Update (context=0x4, input=0x20002 Address 0x20002 out
of bounds, inputLen=3281518976) at /usr/src/sys/kern/md5c.c:172
#8 0xc049fc21 in procfs_doprocfile (td=0xc3980180, p=0xc4951a98,
pn=0xc1fe7c00, sb=0xe72317f0, uio=0x0) at /usr/src/sys/fs/procfs/procfs.c:73
#9 0xc04a3e90 in pfs_readlink (va=0x0) at pcpu.h:157
#10 0xc053cbb8 in kern_readlink (td=0xc3980180, path=0x0,
pathseg=UIO_USERSPACE, buf=0x0, bufseg=UIO_USERSPACE, count=1024) at
vnode_if.h:925
#11 0xc053cade in readlink (td=0xc3980180, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:2197
#12 0xc0601e4f in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135512892, tf_esi =
135663632, tf_ebp = -1077940936, tf_isp = -417129116, tf_ebx = 674101364,
tf_edx = -1077941960, tf_ecx = 0, tf_eax = 58, tf_trapno = 135517392, tf_err
= 2, tf_eip = 672575044, tf_cs = 31, tf_eflags = 647, tf_esp = -1077942020,
tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1014
#13 0xc05ef8ff in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:201
#14 0x002f in ?? ()
#15 0x002f in ?? ()
#16 0x002f in ?? ()
#17 0x0813c33c in ?? ()
#18 0x08161010 in ?? ()
#19 0xbfbfed38 in ?? ()
#20 0xe7231d64 in ?? ()
#21 0x282df874 in ?? ()
#22 0xbfbfe938 in ?? ()
#23 0x in ?? ()
#24 0x003a in ?? ()
#25 0x0813d4d0 in ?? ()
#26 0x0002 in ?? ()
#27 0x2816ae44 in ?? ()
#28 0x001f in ?? ()
#29 0x0287 in ?? ()
#30 0xbfbfe8fc in ?? ()
#31 0x002f in ?? ()
#32 0x in ?? ()
#33 0x in ?? ()
#34 0x in ?? ()
#35 0x in ?? ()
#36 0x0bf63000 in ?? ()
#37 0xc3984a98 in ?? ()
#38 0xc3980180 in ?? ()
#39 0xe7231600 in ?? ()
#40 0xe72315e8 in ?? ()
#41 0xc1efc780 in ?? ()
#42 0xc04f105f in sched_switch (td=0x8161010, newtd=0x282df874, flags=Cannot
access memory at address 0xbfbfed48
) at /usr/src/sys/kern/sched_4bsd.c:881
Previous frame inner to this frame (corrupt stack?)
(kgdb)
Regards,
Geoff Garside
You may try the following patch (this seems to be the issue I fixed recently
in HEAD and RELENG_6). On the other hand, I do not know right locking protocol
for RELENG_5.
Index: fs/procfs/procfs.c
===
RCS file: /usr/local/arch/ncvs/src/sys/fs/procfs/procfs.c,v
retrieving revision 1.11.2.1
diff -u -r1.11.2.1 procfs.c
--- fs/procfs/procfs.c 31 Jan 2005 23:25:58 - 1.11.2.1
+++ fs/procfs/procfs.c 14 Feb 2007 17:59:12 -
@@ -69,10 +69,12 @@
{
char *fullpath = unknown;
char *freepath = NULL;
+ struct vnode *textvp;
- vn_lock(p-p_textvp, LK_EXCLUSIVE | LK_RETRY, td);
- vn_fullpath(td, p-p_textvp, fullpath, freepath);
- VOP_UNLOCK(p-p_textvp, 0, td);
+ textvp = p-p_textvp;
+
Re: portupgrade O(n^m)?
On Wed, 14 Feb 2007 11:41:33 -0600, David Gilbert [EMAIL PROTECTED] wrote: I have 734 ports installed on my laptop right now. I'm pretty sure, at times, I've had over 1000 ports on my laptop. On machine with moderate numbers of ports (most servers seem to have 50 to 200 ports), portupgrade takes a moderate amount of time to start work. On machines like my laptop, portupgrade seems to take much more time to run. I assume it's solving the dependency graph before it decides what to upgrade first, but is this truly a O(n^2) problem? It seems like the implemented algorithm is O(n^2). Give ports-mgmt/portmaster a try. Cheers, Mezz Dave. -- [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src) http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED] http://wiki.freebsd.org/multimedia - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade O(n^m)?
Jeremy == Jeremy Messenger [EMAIL PROTECTED] writes: Jeremy Give ports-mgmt/portmaster a try. I just did. One flaw it has is that I have two no longer supported ports installed. I want to run portmaster -a, but when it finds tund (and I assume it would also stop for xsysinfo), it stops. I put a file '+IGNOREME' in the pkg directories for these two ports, but the process continues to stop. I'd rather not just delete their package info --- it is still correct. Dave. -- |David Gilbert, Independent Contractor. | Two things can be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade O(n^m)?
Joerg Sonnenberger wrote: Well, the complexity is somewhere in the area of O(nm) with m being small. I strongly suggest some basic bucket hashing if it is not done already. For the pkgsrc bulk build (which has similiar problems) it reduced the time to around 3 minutes to resolve all dependencies (6k packages), initally it was somewhere in the area of 1h. The problem is the so called topological sorting of a DAG which is of order (n+m) where n is the number of nodes and m the number of arrows in the DAG. In my python program pkgupgrade, i perform this sorting for the whole set of ports (16000 +) in a couple of seconds. I am quite sure that portupgrade uses one of the standard algorithms so i doubt very much that the problem is here. I suspect it is much more in the constant appeal to databases instead of bringing all data in memory, plus the natural slowness of ruby. Portmaster in no way solves this problem, nor helps upgrading in reasonable time. Portupgrade is an excellent program, very polished, and you will not find much better for source upgrading. A lot of time is lost in pkg_delete() and pkg_add() which, while written in C are very inefficient. I have measured that for removal et reinstallation of around 500 ports at full speed (with a shell script driving the operation and all binary packages present) you need around 2 hours. No program efficient or not, can do without spending these 2 hours, plus the time of downloading the packages, plus the time of doing backups with portupgrade. If you envision compiling from source like portmaster does, then you can go to sleep and come back next morning, hoping that it did not stop after the first few ports. -- Michel TALON ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: portupgrade O(n^m)?
Michel Talon wrote: Joerg Sonnenberger wrote: Well, the complexity is somewhere in the area of O(nm) with m being small. I strongly suggest some basic bucket hashing if it is not done already. For the pkgsrc bulk build (which has similiar problems) it reduced the time to around 3 minutes to resolve all dependencies (6k packages), initally it was somewhere in the area of 1h. The problem is the so called topological sorting of a DAG which is of order (n+m) where n is the number of nodes and m the number of arrows in the DAG. In my python program pkgupgrade, i perform this sorting for the whole set of ports (16000 +) in a couple of seconds. I am quite sure that portupgrade uses one of the standard algorithms so i doubt very much that the problem is here. I suspect it is much more in the constant appeal to databases instead of bringing all data in memory, plus the natural slowness of ruby. Portmaster in no way solves this problem, nor helps upgrading in reasonable time. Portupgrade is an excellent program, very polished, and you will not find much better for source upgrading. A lot of time is lost in pkg_delete() and pkg_add() which, while written in C are very inefficient. I have measured that for removal et reinstallation of around 500 ports at full speed (with a shell script driving the operation and all binary packages present) you need around 2 hours. No program efficient or not, can do without spending these 2 hours, plus the time of downloading the packages, plus the time of doing backups with portupgrade. If you envision compiling from source like portmaster does, then you can go to sleep and come back next morning, hoping that it did not stop after the first few ports. Give me a few weeks, and if I can band together with a few people I wanted to try and port sections of portupgrade and its related tools to C++ (and maybe do some code tweaks along the way). Most of the ruby files are over 400 lines long, sparsely commented, and I don't know ruby enough to port right now, but I've been making some headway lately so I'll try porting some stuff soon. Again, any help with this endeavor would be much appreciated and would greatly speed up the process. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
