Re: Why do soft interrupt coelescing?
Kenneth D. Merry wrote: If the receive ring for that packet size is full, it will hold off on DMAs. If all receive rings are full, there's no reason to send more interrupts. I think that this does nothing, in the FreeBSD case, since the data from the card will generally be drained much faster than it accrues, into the input queue. Whether it gets processed out of there before you run out of mbufs is another matter. [ ... ] Anyway, if all three rings fill up, then yes, there won't be a reason to send receive interrupts. I think this can't really happen, since interrupt processing has the highest priority, compared to stack processing or application level processing. 8-(. OK, assuming you meant that the copies would stall, and the data not be copied (which is technically the right thing to do, assuming a source quench style livelock avoidance, which doesn't currently exist)... The data isn't copied, it's DMAed from the card to host memory. The card will save incoming packets to a point, but once it runs out of memory to store them it starts dropping packets altogether. I think that the DMA will not be stalled, at least as the driver currently exists; you and I agreed on that already (see below). My concern in this case is that, if the card is using the bus to copy packets from card memory to the receive ring, then the bus isn't available for other work, which is bad. It's better to drop the packets before putting them in card memory (FIFO drop fails to avoid the case where a continuous attack pushes all good packets out). The problem is still that you end up doing interrupt processing until you run out of mbufs, and then you have the problem of not being able to transmit responses, for lack of mbufs. In theory you would have configured your system with enough mbufs to handle the situation, and the slowness of the system would cause the windows on the sender to fill up, so they'll stop sending data until the receiver starts responding again. That's the whole purpose of backoff and slow start -- to find a happy medium for the transmitter and receiver so that data flows at a constant rate. In practice, mbuf memory is just as overcommitted as all other memory, and given a connection count target, you are talking a full transmit and full receive window worth of data at 16k a pop -- 32k per connection. Even a modest maximum connection count of ~30,000 connections -- something even an unpatches 4.3 FreeBSD could handle -- means that you need 1G of RAM for the connections alone, if you disallow overcommit. In practice, that would mean ~20,000 connections, when you count page table entries, open file table entries, vnodes, inpcb's, tcpcb's, etc.. And that's a generaous estimate, which assumes that you tweak your kernel properly. One approach to this is to control the window sizes based on th amount of free reserve you have available, but this will actually damage overall throughput, particularly on links with a higher latency. In the ti driver case, the inability to get another mbuf to replace the one that will be taken out of the ring means that the mbuf gets reused for more data -- NOT that the data flow in the form of DMA from the card ends up being halted until mbufs become available. True. This is actually very bad: you want to drop packets before you insert them into the queue, rather than after they are in the queue. This is because you want the probability of the drop (assuming the queue is not maxed out: otherwise, the probabilty should be 100%) to be proportional to the exponential moving average of the queue depth, after that depth exceeds a drop threshold. In other words, you want to use RED. Please look at what happens in the case of an allocation failure, for any driver that does not allow shrinking the ring of receive mbufs (the ti is one example). It doesn't spam things, which is what you were suggesting before, but as you pointed out, it will effectively drop packets if it can't get new mbufs. Maybe I'm being harsh in calling it spam'ming. It does the wrong thing, by dropping the oldest unprocessed packets first. A FIFO drop is absolutely the wrong thing to do in an attack or overload case, when you want to shed load. I consider the packet that is being dropped to have been spam'med by the card replacing it with another packet, rather than dropping the replacement packet instead. The real place for this drop is before it gets to card memory, not after it is in host memory; Floyd, Jacobsen, Mogul, etc., all agree on that. Yes, it could shrink the pool, by just not replacing those mbufs in the ring (and therefore not notifying the card that that slot is available again), but then it would likely need some mechanism to allow it to be notified that another buffer is available for it, so it can then allocate receive buffers again. In practice I haven't found the number of mbufs in the system to be a problem
my dc now doesn't work
After the last cvsup (changes from 29 of september) i've got dead dc (21143 based NIC). LEDs are dead, but card is successfully probed and attached, so i have device but can't use it. What should i send to help investigate this problem? This is strings from working kernel: $FreeBSD: src/sys/dev/mii/amphy.c,v 1.4 2000/12/12 19:31:14 wpaul Exp $ $FreeBSD: src/sys/dev/mii/brgphy.c,v 1.5 2001/09/18 00:31:19 wpaul Exp $ $FreeBSD: src/sys/dev/mii/dcphy.c,v 1.10 2001/03/28 09:17:52 jhb Exp $ $FreeBSD: src/sys/dev/mii/exphy.c,v 1.6 2000/12/12 19:31:14 wpaul Exp $ $FreeBSD: src/sys/dev/mii/mii.c,v 1.8 2001/02/04 16:08:05 phk Exp $ ^^^ $FreeBSD: src/sys/dev/mii/mii_physubr.c,v 1.4 2000/12/12 19:31:14 wpaul Exp $ ^^^ $FreeBSD: src/sys/dev/mii/nsphy.c,v 1.9 2001/06/02 19:51:02 jlemon Exp $ $FreeBSD: src/sys/dev/mii/nsgphy.c,v 1.1 2001/05/11 19:56:36 wpaul Exp $ $FreeBSD: src/sys/dev/mii/pnphy.c,v 1.6 2001/03/28 09:17:52 jhb Exp $ $FreeBSD: src/sys/dev/mii/pnaphy.c,v 1.3 2000/12/12 19:31:14 wpaul Exp $ $FreeBSD: src/sys/dev/mii/rlphy.c,v 1.4 2000/12/12 19:31:14 wpaul Exp $ $FreeBSD: src/sys/dev/mii/tlphy.c,v 1.6 2001/07/19 02:14:59 kris Exp $ $FreeBSD: src/sys/dev/mii/ukphy.c,v 1.5 2000/12/12 19:31:14 wpaul Exp $ $FreeBSD: src/sys/dev/mii/ukphy_subr.c,v 1.4 2000/04/29 15:35:12 phk Exp $ $FreeBSD: src/sys/dev/mii/xmphy.c,v 1.4 2001/05/23 22:10:55 wpaul Exp $ $FreeBSD: src/sys/dev/mii/lxtphy.c,v 1.1 2001/02/07 19:57:16 semenu Exp $ $FreeBSD: src/sys/dev/mii/qsphy.c,v 1.1 2001/02/07 19:57:16 semenu Exp $ $FreeBSD: src/sys/dev/mii/acphy.c,v 1.2 2001/02/07 22:34:15 semenu Exp $ $FreeBSD: src/sys/dev/usb/if_aue.c,v 1.42 2001/09/09 03:08:30 dwhite Exp $ $FreeBSD: src/sys/dev/usb/if_cue.c,v 1.19 2001/08/22 05:33:57 peter Exp $ $FreeBSD: src/sys/dev/usb/if_kue.c,v 1.32 2001/08/22 05:33:57 peter Exp $ $FreeBSD: src/sys/dev/usb/usb_ethersubr.c,v 1.9 2000/11/25 07:35:24 jlemon Exp $ $FreeBSD: src/sys/pci/if_dc.c,v 1.55 2001/09/04 17:10:11 wpaul Exp $ And from the new kernel: $FreeBSD: src/sys/dev/mii/amphy.c,v 1.5 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/brgphy.c,v 1.6 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/dcphy.c,v 1.11 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/exphy.c,v 1.7 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/mii.c,v 1.10 2001/10/01 22:57:57 mjacob Exp $ $FreeBSD: src/sys/dev/mii/mii_physubr.c,v 1.6 2001/09/29 18:48:24 jlemon Exp $ ^^^ $FreeBSD: src/sys/dev/mii/nsphy.c,v 1.10 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/nsgphy.c,v 1.2 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/pnphy.c,v 1.7 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/pnaphy.c,v 1.4 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/rlphy.c,v 1.5 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/tlphy.c,v 1.7 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/ukphy.c,v 1.6 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/ukphy_subr.c,v 1.4 2000/04/29 15:35:12 phk Exp $ $FreeBSD: src/sys/dev/mii/xmphy.c,v 1.5 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/lxtphy.c,v 1.2 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/qsphy.c,v 1.2 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/mii/acphy.c,v 1.3 2001/09/29 19:18:52 jlemon Exp $ $FreeBSD: src/sys/dev/usb/if_aue.c,v 1.43 2001/09/29 19:31:29 jlemon Exp $ $FreeBSD: src/sys/dev/usb/if_cue.c,v 1.19 2001/08/22 05:33:57 peter Exp $ $FreeBSD: src/sys/dev/usb/if_kue.c,v 1.32 2001/08/22 05:33:57 peter Exp $ $FreeBSD: src/sys/dev/usb/usb_ethersubr.c,v 1.9 2000/11/25 07:35:24 jlemon Exp $ $FreeBSD: src/sys/pci/if_dc.c,v 1.56 2001/09/29 19:28:31 jlemon Exp $ my dmesg (from logs) new kernel: Oct 11 11:55:52 ws-ilmar /boot/kernel/kernel: Copyright (c) 1992-2001 The FreeBSD Project. Oct 11 11:55:53 ws-ilmar /boot/kernel/kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Oct 11 11:55:53 ws-ilmar /boot/kernel/kernel: The Regents of the University of California. All rights reserved. Oct 11 11:55:53 ws-ilmar /boot/kernel/kernel: FreeBSD 5.0-CURRENT #2: Wed Oct 10 18:46:23 MSD 2001 Oct 11 11:55:53 ws-ilmar /boot/kernel/kernel: root@ws-ilmar.:/usr/src/sys/i386/compile/WS_ILMAR Oct 11 11:55:53 ws-ilmar /boot/kernel/kernel: Timecounter i8254 frequency 1193182 Hz Oct 11 11:55:53 ws-ilmar /boot/kernel/kernel: Timecounter TSC frequency 706297611 Hz Oct 11 11:55:53 ws-ilmar /boot/kernel/kernel: CPU: AMD Duron(tm) Processor (706.30-MHz 686-class CPU) Oct 11 11:55:53 ws-ilmar /boot/kernel/kernel: Origin = AuthenticAMD Id = 0x631 Stepping = 1 Oct 11 11:55:53 ws-ilmar /boot/kernel/kernel:
Iomega Peerless USB supported?
Hi, Are Iomega Peerless USB drives supported in CURRENT? I assume they can be recognised as a generic SCSI-over-USB drive, but want to be sure they work OK. Thanks, Konstantin. -- * * Konstantin Chuguev Francis House * * Application Engineer 112 Hills Road * Tel: +44 1223 302992 Cambridge CB2 1PQ D A N T E WWW: http://www.dante.netUnited Kingdom To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Error compiling kernel
cvsuped two days ago, and made buildworld today, which went OK. Tried make kernel (aka GENERIC). It fails at nfsclient code: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W missing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -an si -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contri b/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/../include -D_KERNE L -include opt_global.h -elf -mpreferred-stack-boundary=2 /usr/src/sys/nfsclie nt/nfs_socket.c /usr/src/sys/nfsclient/nfs_socket.c: In function `nfs_msg': /usr/src/sys/nfsclient/nfs_socket.c:1368: warning: left-hand operand of comma ex pression has no effect /usr/src/sys/nfsclient/nfs_socket.c:1368: warning: left-hand operand of comma ex pression has no effect /usr/src/sys/nfsclient/nfs_socket.c:1368: warning: left-hand operand of comma ex pression has no effect /usr/src/sys/nfsclient/nfs_socket.c:1368: warning: left-hand operand of comma ex pression has no effect /usr/src/sys/nfsclient/nfs_socket.c:1368: warning: left-hand operand of comma ex pression has no effect /usr/src/sys/nfsclient/nfs_socket.c:1368: syntax error before `)' *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Any clues? -- __o regards, Gunnar ---_ \,_ email: [EMAIL PROTECTED] (_)/ (_) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Error compiling kernel
On 11-Oct-01 Gunnar Flygt wrote: cvsuped two days ago, and made buildworld today, which went OK. Tried make kernel (aka GENERIC). It fails at nfsclient code: Already fixed two days ago. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PAM NIS?
The latest installworld seems to not be happy with me in NIS- I get: Oct 11 09:47:39 quarm sshd[8160]: PAM pam_set_item: NULL pam handle passed Oct 11 09:47:39 quarm sshd[8160]: PAM pam_set_item: NULL pam handle passed Oct 11 09:47:39 quarm sshd[8160]: PAM pam_set_item: NULL pam handle passed To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Approach to integrate a driver into the kernel [winmodem]
From: Brandon D. Valentine [EMAIL PROTECTED] On Thu, 11 Oct 2001, Benjamin Close wrote: I've now been using the FreeBSD winmodem driver (Available at: http://www.geocities.com/wtnbkysh/) under -current for a few weeks now and haven't noticed a single glitch. Whilst I know this is a port of a linux drivers and contains a binary only object from Lucent. Is there any chance of getting this as part of the FreeBSD kernel? There is a lot of people out in laptop land who would welcome this. I would think the license probably precludes it from inclusion. If you want to push for commital you might do well to research a bit about how Lucent licenses their WinModem driver under Linux, then find out if the patches at that site you listed are BSD licensed. If your email contains that info it probably has a better chance of getting attention. If the license on the kernel module is incompatible with the base system, you might be able to get the hooks to support it committed to FreeBSD and get the kernel modules made installable as a port. /usr/local/modules anyone? =) The kernel module has this copy right in it's ltmdmsio.c file: Copyright (c) 1991 The Regents of the University of California. Upon doing a search for i56lvp578, I located a license for the ltmdmobj.o file (see ltmodem-6.00b4.tar.gz at http://www.heby.de/ltmodem): Software sources and responsibilities. -- Agere Systems, Inc, (AS herein is a branch of Lucent Technologies, Inc.) AS provides the core Digital Signal Processor (DSP) code supporting the Mars/Apollo chipset used in the compatible modems. Diverse manufacturers incorporate the chips onto diverse modem cards, generally optimizing them for use under MS Windows. AS has NO responsibility for downstream modem functionality under Linux.!! Please do not annoy AS with support queries !! The List [EMAIL PROTECTED] is the only medium for the current support of these modems under Linux. Origins of the ltmodem-5.nn series kits enhancing upon the AS base are described in DOCs/CREDITS. These resources are used at your own risk. I didn't see any other licenses in the ltmodem-6.00b4.tar.gz archive. One of the other sites mentioned that the linux ltmodem driver was GPL'd, but they also complained about the non-availablility of the source for the ltmdmobj.o file, claiming that since the linux ltmodem driver is GPL'd that the ltmdmobj.o file is also and source code should be available for it. My best guess is that the ltmdmobj.o file is the DSP code from Agere Systems, and that Agere Systems holds the copyright on it. We would need verification from Agere Systems ([EMAIL PROTECTED] ?) before including the ltmdmobj.o file. Until the license is clarified, we could make a port for the FreeBSD ltmodem driver. Scot To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my dc now doesn't work
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write: After the last cvsup (changes from 29 of september) i've got dead dc (21143 based NIC). LEDs are dead, but card is successfully probed and attached, so i have device but can't use it. What should i send to help investigate this problem? $FreeBSD: src/sys/pci/if_dc.c,v 1.56 2001/09/29 19:28:31 jlemon Exp $ Can you back out this last change to if_dc, and see if that fixes the problem that you're having? -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: my dc now doesn't work
After the last cvsup (changes from 29 of september) i've got dead dc (21143 based NIC). You have to tell us _exactly_ what card you have. Find the manufacturer and model info. Look on the box the card came in. Look at the card itself. Show us the output from pciconf -l so we can see the PCI vendor/device ID info. Yes, this information is important. Yes, I'm irritated that you didn't provide it straight off. (But then nobody ever does. Guys? You don't need me to ask you to provide this information. It's common sense. It's staring you right in the face.) LEDs are dead, but card is successfully probed and attached, so i have device but can't use it. What should i send to help investigate this problem? Knowing exactly what card this is will help. You can't debug this problem: I'm going to have to figure out a way to test and debug this myself, which is going to suck, as I no longer have an easy way to do FreeBSD work now that Wind River has pulled the plug on the test lab. If you want to be really nice, you can arrange to have this machine made accessible remotely (via an alternate network interface) and let me tinker with it via ssh. Otherwise, you'll have to wait for me to put together a test setup locally. Oct 11 11:57:37 ws-ilmar /boot/kernel.old/kernel: dc0: Ethernet address: 00:80:ad:90:b4:38 Oct 11 11:57:37 ws-ilmar /boot/kernel.old/kernel: miibus0: MII bus on dc0 Oct 11 11:57:37 ws-ilmar /boot/kernel.old/kernel: dcphy0: Intel 21143 NWAY media interface on miibus0 Oct 11 11:57:37 ws-ilmar /boot/kernel.old/kernel: dcphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto I strongly suspect that the recent changes to the miibus code by jlemon have hosed the dcphy driver, which is very sensitive. (You don't want to know how long it took me to get it working halfway decently.) -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Protect yourself !
When was the last tragedy you were involved in? The next one could be the last!! REMEMBER, 80% of sinister fatalities occur due to toxic gases and smoke inhalation. OUR PRODUCT CAN SAVE YOUR LIFE OR THE LIFE OF A LOVED ONE ORDER NOW ! Click HERE for more info : http://www.life-protect.com/partner.cgi?Partner=1011 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI panic at boot time in -current
Hi, I was wondering if anybody has any suggestions about why this might be happening in -current: Booting [/boot/kernel/kernel]... /boot/kernel/acpi.ko text=0x32f34 data=0xf9c+0x1028 syms=[0x4+0x49c0+0x4+0x61a]- Copyright (c) 1992-2001 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.0-CURRENT #5: Wed Oct 10 06:33:14 BST 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HAK Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 97342057 Hz CPU: Pentium II/Pentium II Xeon/Celeron (97.34-MHz 686-class CPU) Origin = GenuineIntel Id = 0x66a Stepping = 10 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 201261056 (196544K bytes) avail memory = 191459328 (186972K bytes) Preloaded elf kernel /boot/kernel/kernel at 0xc043e000. Preloaded elf module /boot/kernel/snd_neomagic.ko at 0xc043e0a8. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc043e15c. Preloaded elf module /boot/kernel/acpi.ko at 0xc043e208. Pentium Pro MTRR support enabled VESA: v2.0, 2496k memory, flags:0x0, mode table:0xc0354cc2 (122) VESA: MagicGraph 256 AV 48K Using $PIR table, 6 entries at 0xc00fdf60 npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfcf0-0xfcff at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller at device 7.2 on pci0 uhci0: Could not map ports device_probe_and_attach: uhci0 attach returned 6 pci0: bridge, PCI-unknown at device 7.3 (no driver attached) pci0: display, VGA at device 8.0 (no driver attached) pcm0: NeoMagic 256AV mem 0xfec0-0xfecf,0xfe00-0xfe3f irq 9 at device 8.1 on pci0 pci0: serial bus, FireWire at device 9.0 (no driver attached) pccbb0: RF5C478 PCI-CardBus Bridge irq 0 at device 10.0 on pci0 pccbb0: PCI Memory allocated: 1000 acpi_pcib0: device is routed to IRQ 9 cardbus0: Cardbus bus (newcard) on pccbb0 pccard0: 16-bit PCCard bus on pccbb0 pccbb1: RF5C478 PCI-CardBus Bridge irq 0 at device 10.1 on pci0 pccbb1: PCI Memory allocated: 10001000 acpi_pcib0: possible interrupts: 9 panic: free: multiple freed item 0xc14f75f0 Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db t Debugger(c02d159b) at Debugger+0x44 panic(c02d0031,c14f75f0,0,c14f75f0,c0460adc) at panic+0x70 free(c14f75f0,c0430ba0,c0460a6c,c041f218,c14f75f0) at free+0x197 AcpiOsFree(c14f75f0,1,c150be9c,c0460b2c,c14ef9c0) at AcpiOsFree+0x10 AcpiRsSetSrsMethodData(c14e57a0,c0460adc,c0460b64,c0427626,c14e57a0) at AcpiRsSetSrsMethodData+0xc4 AcpiSetCurrentResources(c14e57a0,c0460adc,c14d5188,c14f3c80,c14f9d88) at AcpiSetCurrentResources+0x2b acpi_pcib_route_interrupt(c14f3c80,c14f9d00,1) at acpi_pcib_route_interrupt+0x6a2 pci_alloc_resource(c14f8700,c14f9d00,1,c0460c0c,0) at pci_alloc_resource+0xa6 bus_alloc_resource(c14f9d00,1,c0460c0c,0,) at bus_alloc_resource+0x5d pccbb_attach(c14f9d00,c14f9d00,c14f3c80,c14f8700,0) at pccbb_attach+0x3d0 device_probe_and_attach(c14f9d00) at device_probe_and_attach+0x9a bus_generic_attach(c14f8700,c14f8700,c0cdb680,c14f4a40,1) at bus_generic_attach+0x16 device_probe_and_attach(c14f8700) at device_probe_and_attach+0x9a bus_generic_attach(c14f3c80,c14d5088,c0cdb680,c14f3c80,c0460c90) at bus_generic_attach+0x16 acpi_pcib_attach(c14f3c80,c14f3c80,c0cdb680,c0cdb680,0) at acpi_pcib_attach+0x189 device_probe_and_attach(c14f3c80) at device_probe_and_attach+0x9a bus_generic_attach(c0cdb680,c0cdb61c,c0cdb600,c0cd2560,c0460cf8) at bus_generic_attach+0x16 acpi_probe_children(c0cdb680,c14cd088,c0cdb880,c0cdb680,6) at acpi_probe_children+0x62 acpi_attach(c0cdb680,c0cdb680,c0cdb880,c0cdb880,1) at acpi_attach+0x1d5 device_probe_and_attach(c0cdb680) at device_probe_and_attach+0x9a bus_generic_attach(c0cdb880,c14a6088,c0cdbb80,c0460d5c,c01c2786) at bus_generic_attach+0x16 nexus_attach(c0cdb880,c0cdb880,c0cd8dc8,465000,1) at nexus_attach+0xe device_probe_and_attach(c0cdb880) at device_probe_and_attach+0x9a root_bus_configure(c0cdbb80,c02f07c0,0,4) at root_bus_configure+0x16 configure(0,45dc00,45d000,0,c0126aac) at configure+0x22 mi_startup() at mi_startup+0x90 begin() at begin+0x43 Cheers. -- Brian [EMAIL PROTECTED][EMAIL PROTECTED] http://www.freebsd-services.com/brian@[uk.]FreeBSD.org Don't _EVER_ lose your sense of humour !
Patch: mfsroot.flp to include more and more kernel modules
I've posted (old version of) this patch before at cvs-committers, but [EMAIL PROTECTED] is more appropriate list so I post a new version of patch here. *** Attached below is a patch to make more kernel-modularize installation flopppies. - Why need this? Because we have very few space in kern.flp since kernel itself becomes bigger than before. Kernel core should be in the kernel, but drivers can be move out to kernel module. - What's changed? 1) ed, fe, lnc, sl, tun, txp, vx, asr, mly, amr, mlx, and twe drivers are moved from the kernel to kernel modules. These modules are put into mfsroot.flp. 2) bge and lge, our gigabit ethernet drivers, are also added to GENERIC kernel (just missing I think). These two drivers are also modularized in mfsroot.flp. 3) In fact, there are already several kernel modules in a mfsroot.flp. To reduce the size of modules, ALL kernel modules are combined into a single one. - OK, how many bytes we can get in kern.flp? Any advantages/disadvantages? Before patch: kern.flp 59 kbytes left mfsroot.flp 311 kbytes left After patch: kern.flp139 kbytes left mfsroot.flp 167 kbytes left We have 80 kbytes free space in kern.flp, and losts 144 kbytes in mfsroot.flp. But don't forget that we have also get two new drivers (bge and lge). There are something to blush up in my patch, but if you wanna test these 'merged kernel modules, have [bl]ge drivers' installation floppies now, try: URL:http://home.jp.FreeBSD.org/~matusita/more-kld-floppies/boot.flp URL:http://home.jp.FreeBSD.org/~matusita/more-kld-floppies/kern.flp URL:http://home.jp.FreeBSD.org/~matusita/more-kld-floppies/mfsroot.flp If you have any comments on this, please feel free to send to me. P.S.: I've tested kern.flp/mfsroot.flp with my VMware 3.0beta box, and work fine (kernel detects VMware ethernet device as lnc1). -- - Makoto `MAR' MATSUSHITA Index: sys/i386/conf/GENERIC === RCS file: /pub/cvsup/FreeBSD.cvs/src/sys/i386/conf/GENERIC,v retrieving revision 1.322 diff -u -r1.322 GENERIC --- sys/i386/conf/GENERIC 25 Sep 2001 18:56:37 - 1.322 +++ sys/i386/conf/GENERIC 10 Oct 2001 05:16:50 - @@ -166,8 +166,10 @@ # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support +device bge # Broadcom BCM570x gigabit ether device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) +device lge # Level 1 LXT1001 NetCellerator gigabit ether device pcn # AMD Am79C97x PCI 10/100 NICs device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') Index: release/i386/drivers.conf === RCS file: /pub/cvsup/FreeBSD.cvs/src/release/i386/drivers.conf,v retrieving revision 1.2 diff -u -r1.2 drivers.conf --- release/i386/drivers.conf 7 Nov 2000 14:00:04 - 1.2 +++ release/i386/drivers.conf 11 Oct 2001 18:12:27 - @@ -35,24 +35,46 @@ # #drv filenamefloppy typedescription -an if_an 2 network Aironet 4500/4800 802.11 PCMCIA/ISA/PCI card -#aue if_aue 2 network ADMtek USB ethernet adapter -#cue if_cue 2 network CATC USB ethernet adapter -dc if_dc 2 network DEC/Intel 21143 (and clones) PCI fast ethernet card -de if_de 2 network DEC DE435 PCI NIC or other DC21040-AA based card -fxpif_fxp 2 network Intel EtherExpress Pro/100B PCI Fast Ethernet card -#kue if_kue 2 network Kawasaki LSI USB ethernet adapter -pcnif_pcn 2 network AMD Am79c79x PCI ethernet card -rl if_rl 2 network RealTek 8129/8139 PCI ethernet card -sf if_sf 2 network Adaptec AIC-6915 PCI ethernet card -sisif_sis 2 network SiS 900/SiS 7016 PCI ethernet card -sk if_sk 2 network SysKonnect PCI gigabit ethernet card -steif_ste 2 network Sundance ST201 PCI ethernet card -ti if_ti 2 network Alteon Networks PCI gigabit ethernet card -tl if_tl 2 network Texas Instruments ThunderLAN PCI ethernet card -tx if_tx 2 network SMC 9432TX ethernet card -vr if_vr 2 network VIA VT3043/VT86C100A Rhine PCI ethernet card -wb if_wb 2 network Winbond W89C840F PCI ethernet card -wi if_wi 2
Protect yourself !
When was the last tragedy you were involved in? The next one could be the last!! REMEMBER, 80% of sinister fatalities occur due to toxic gases and smoke inhalation. OUR PRODUCT CAN SAVE YOUR LIFE OR THE LIFE OF A LOVED ONE ORDER NOW ! Click HERE for more info : http://www.life-protect.com/partner.cgi?Partner=1011 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
current.freebsd.org successfully building snapshots again
drwxr-xr-x 20 root wheel 1024 Oct 11 22:17 5.0-20011011-CURRENT Come 'n get it. No warrantees stated or implied as to how far these bits get you after you transfer them, of course. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Strike three, you're out
For the first time in as long as I can remember (several years at least), I've backed my workstation at home down to -STABLE. The three problems I'm having currently are just too much for me to put up with, and at this point in my life I need something that works. Yes... I know that this is an excellent reason to go back to -stable, so why am I bothering to write the list about it? Basically in the hopes that these things will get some attention. Reported on 9/30: panic: blockable sleep lock (sx) allproc @ /usr/local/src/sys/kern/kern_proc.c:212 According to BDE, This is a well-know bug in printf(9). The TIOCCONS ioctl always gave non-deterministic crashes. Now it gives determinstic panics when pintf() is called while sched_lock is held. That's the only discussion about it, no fixes, no suggestions. Ok, I can live without that one, but, Reported on 9/30: Any releng_4 apps that I tried to run on my -current system could not resolve hostnames. This included cvsup and yahoo! messenger. This was a show stopper for me. The only suggestion I received was to make sure that I didn't have any old libs laying around, which I did; and install COMPAT4x, which I also did. Updating -current every other day to see if something magic happened led me to, Reported on 10/6: Soren's ATA upgrade caused kernel panic on boot. Soren was kind enough to discuss these changes with me, which were necessary to accomodate some laptop users. However, he hasn't had a chance to find a middle ground yet. So, in the process of backing the above change out, the kernel I came up with crashed, and corrupted my / partition (which wasn't ata related, since my hd's in that system are scsi). So, rather than repair it, I replaced it. I've always felt strongly that developers should have at least one -current install around to work on, and I've always had good luck from following the lists, updating judiciously, etc. I know that people who can't afford broken stuff shouldn't run -current on key systems, which is why I've downgraded. I've always been willing to do what I can to debug, test, report, etc. But three nasty problems with no help is more than I can deal with right now. Hoping it gets better soon, Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
