Re: mbuf doubts
Giovani, you will find the answer to your question in tcp/ip illustrated, volume 2: the implementation in chapter 2. But to briefly answer your question, yes, there are 4 different types of mbufs, depending on the m_flags value. 1) m_flags = 0 and mbuf contains only data up to 108 bytes. 2) m_flags = M_PKTHDR to designate a packet header. 3)m_flags = M_EXT. In a situation where a user process write() in a buffer 256 bytes, the system allocates a cluster to hold that data. 4) m_flags = M_EXT|M_PKTHDR and yes when using clusters, the memory in the mbuf is unsed. hop that helped. Jerry On Tuesday 23 September 2003 07:12 pm, Giovanni P. Tirloni wrote: Hi, I have been reading the DI chapter about IPC, specially the mbuf section and *many* doubts were raised by my mind. I sending them here in the hope that someone can clarify some bits for me so I can proceed. Reading sys/param.h and sys/mbuf.h I came to the conclusion that there are four types of mbufs regarding it's allocation of memory for data. Is the listing below correct? struct mbuf *m; 1. Normal mbuf using m-M_databuf 2. Normal mbuf with external storage (cluster?) in m-m_hdr-mh_data 3. Header mbuf using m-m_pktdat; 4. Header mbuf with ext. storage (cluster?) in m-m_ext-ext_buf Other questions: 1. When using ext. storage is the space allocated by M_databuf wasted? 2. How the system decides 256 bytes for each mbuf isn't enough and it needs a mbuf cluster? Isn't chaining useful there? 3. How does changing MSIZE affects the whole thing? 4. What about MCLBYTES? Sorry to make so many questions at once but I find it very interesting and I'm really willing to learn how the building blocks of the network stack work. Perhaps my questions are out of reality.. it's risk. Thanks, -- Giovanni P. Tirloni gpt at tirloni.org Fingerprint: 8C3F BEC5 79BD 3E9B EDB8 72F4 16E8 BA5E D031 5C26 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
USB card overcurrent problems...
[Drop hostname part of IPv6-only address above to obtain IPv4-capable e-mail, or just drop me from the recipients and I'll catch up from the archives] Hello every last one of you, First, before I spout off in the wrong forum, is there a better or preferred location for USB-hardware-related questions like that which follows, akin to the firewire list? Okay, the question: I have two cards with USB2.0 awareness, used for their USB 1.x capability under FreeBSD 4.x. One of them, a UHCI card, works just fine, but the other one, an OHCI card, out-of-the-box exhibits problems. Chipset is identified in dmesg as NEC uPD 9210 USB controller. What happens, when I put it in a machine that it doesn't promptly wedge at boot or soon afterwards, is that the uhub/ohci USB codes from 4.5-RC up to 4.7 of last December (and now even recent 4.9-prerelease codes; haven't tried the NetBSD codes they originate from) result in the internal hub going dead (being disabled) when a bus-powered external USB2 hub device is connected to it -- the other card (UHCI) has no problems with repeated attach/detaches of this external hub. There is no obvious problem when connecting a self-powered device like that external hub with wall wart, or an external hard drive. Observation of the power indicator on the external hub shows that at time of attachment, it lights very briefly and then immediately goes out, and repeated unplug/re-plugging of the USB cable results in no further activity. Adding copious debuggery to the kernel indicates that at time of connecting the hub, the status of the internal port changes to unpowered and the change variable has the overcurrent bit set. Assuming that I don't have a truly wimpy piece of hardware (I haven't tried it under any non-*BSD OSen), it should durn well be able to power this hub, but perhaps the power-on surge of current into the filter capacitors is triggering this (temporary?) overcurrent indication. In fact, I was able to get the power indicator to come on and stay lit on the external hub by checking for an overcurrent condition in uhub.c, and then clearing the bit and re-applying power. Not 100% reliably, but later hacking (this evening) seems to have improved that, at the risk of ignoring a Real Overcurrent indication. What would be the proper changes to the code, after testing for such an overcurrent condition, in order to safely reapply power until such condition clears? Adding a delay somewhere? Limiting the number of times I try to re-apply power before bailing? (This last boot took some 5 or 6 tries until it came up okay in a tight loop) (There are comments in the source, imported from NetBSD, that some work- arounds for an overcurrent problem have been applied, but those did not seem to make any difference to me. Also, as noted, I haven't yet tried NetBSD from which these workarounds came, to see if there may be any not- yet-imported fixes that make my device work.) Also, I found that when applying the power within the test for overcurrent, that clearing the overcurrent change did not necessarily re-enable the interrupts, so I added that test to the routine that applies power, if that's safe to do. I'm probably not describing things well, but I'm positive my hacks aren't at all proper, so I'd rather learn the right way to handle this case before explaining where I run into problems. And, I'll have more USB-related questions later, so pointers to the proper place for those would be appreciated, if this list isn't it. Thanks, Barry Bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel module problems/questions
[You know the drill: drop my hostname from the above IPv6-only address to get an IPv4-capable address; drop me entirely to avoid bounces and I'll catch the archives before your mail might reach me if it doesn't bounce] Some stupid kernel module questions. Kernel source from a few days ago, RELENG_4. First, why would USB-related modules whose source explicitly declares a DEPEND on the usb.ko module, fail to auto-load the usb module when they're kldload'ed? They fail with various undefined symbol errors, and there's no trace of any attempt to load the usb module. Second, why do some USB devices declare a module dependency on usb, while others (say, umass) do not? Ignoring that the usb auto-load fails for now. Third, if I load the usb.ko module by hand, everything works, except that I can't unload the usb.ko module. The error is `Device not configured.' To make this a question, I'll add: Why is this? Fourth, after boot, if I load, say, sbp.ko, it auto-loads firewire.ko, and attempts to unload firewire are denied so long as sbp.ko remains loaded. But if at boot, I've mangled the loader.conf to load sbp.ko, which then auto-loads firewire.ko, I *am* able to unload firewire.ko later by hand. Then unloading sbp.ko promptly results in a kernel panic. So, why can I unload modules auto-loaded at boot, when I'm denied unloading the same modules auto-loaded after boot? The desired behaviour would be *not* to be able to unload any auto-loaded modules, regardless. Fifth, I've run out of questions for now. Tune in again later. Thanks, Barry Bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Machine wedges solid after one serial-port source-lineaddition...
[Drop hostname part of IPv6-only address above to obtain IPv4-capable e-mail, or just drop me from the recipients and I'll catch up from the archives] Terry Lambert writes: I remember wakeup() being bad. Taking any time to do anything at all more than just queueing data and going away is probably bad. Then that's probably why it worked fine for some hours, then failed miserably. Thanks! If it were my project, I'd mirror the values out to a status structure that's only written at interrupt, and read and reset at software interrupt, and then use the soft interrupt handler to raise the signals/send the wakeup/whatever and then resets the flags bits to zero via a call down that synchronizes like Maybe I'll turn back to this, when I'm older and wiser. But also, serial ports are a scarcity for me, so I'm wondering what else I can use to get precise timing information, to free up the serial port for something else. I wrote earlier (from an invalid address that probably most list readers rejected as spam) that I had a problem accessing the parallel port nACK as /dev/pps for the precise timing already present in the kernel source, and simultaneously as /dev/ppi for coarse timing via polling from which I'd determine the time that the PPS signal refers to. I tried adding printf()s to various parallel-port kernel code to see if there might be an interrupt I could jump onto for each transition of the nACK status line, but I suspect my lack of success with both swings of the signal has to do with not doing it right. So I'll ask a basic question here, forgive my ignorance: Can the lines of the parallel port be used to generate interrupts that I can use, in the same way that I've been able to use the four serial port status lines, or is this right out? And another question, I see three unused joystick connectors on the three sound cards in my machine, that are less likely to be used than the so-far- unused parallel port. Would it be possible to get interrupts from the sound card's joystick connector, when interfaced with suitable hardware to the radio clock output, that I would also theoretically be able to use? Or is this also something I'd need to poll the status of the switch(es), so only coarse precision would be possible? Please excuse my basic ignorance of fundamental PC hardware principles, and I'll welcome pointers to sources of more knowledge. Thanks, Barry Bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
[obligatory From: address is IPv6-only; to obtain IPv4-mailable address, remove hostname part. Even then no guarantee mail won't bounce -- I follow the list archives in my copious offline time] In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of I have no idea of how well either of these work. Use your own discretion at applying them. djbdns-1.05-ignoreip2.patch seems to work very well here, on three A stupid question, no less, since I see this being discussed here -- is it correct that the ISC BIND patch does not work with a nameserver that's set up as a forward-only box? I've applied the patch to a random BIND successfully, but I'm configured as forward-only for the domains I don't dish out, being on the unpleasant end of a PPP dial-in and trying to do my part to keep the root nameservers' load down. I nab the ISP-provided DNS addresses during the PPP handshake, configure them as forwarders (plus one or two backups) and restart named, but still I was able to resolve a made-up com domain to the Usual Address. This tells me I need to use the DNS machines of an ISP with Clue as static forwarder addresses, not those provided by ISP-of-the-day (and the last ISP seemed to give horribly broken machines anyway), if this reaches a point where I actually want to do something about these wildcards. Provided the ISP allows outgoing DNS queries too. Thanks, Barry Bouwsma ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mbuf doubts
* Jerry Toung ([EMAIL PROTECTED]) wrote: Giovani, you will find the answer to your question in tcp/ip illustrated, volume 2: the implementation in chapter 2. But to briefly answer your question, yes, there are 4 different types of mbufs, depending on the m_flags value. 1) m_flags = 0 and mbuf contains only data up to 108 bytes. 2) m_flags = M_PKTHDR to designate a packet header. 3)m_flags = M_EXT. In a situation where a user process write() in a buffer 256 bytes, the system allocates a cluster to hold that data. 4) m_flags = M_EXT|M_PKTHDR and yes when using clusters, the memory in the mbuf is unsed. hop that helped. Thank you very much Justin and Jerry for the answers. They were very helpful. I'm already getting my copy of Steven's :-) -- Giovanni P. Tirloni gpt at tirloni.org Fingerprint: 8C3F BEC5 79BD 3E9B EDB8 72F4 16E8 BA5E D031 5C26 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB card overcurrent problems...
On Wed, Sep 24, 2003 at 06:32:42PM +0200, Barry Bouwsma wrote: [Drop hostname part of IPv6-only address above to obtain IPv4-capable e-mail, or just drop me from the recipients and I'll catch up from the archives] Hello every last one of you, First, before I spout off in the wrong forum, is there a better or preferred location for USB-hardware-related questions like that which follows, akin to the firewire list? Okay, the question: I have two cards with USB2.0 awareness, used for their USB 1.x capability under FreeBSD 4.x. One of them, a UHCI card, works just fine, but the other one, an OHCI card, out-of-the-box exhibits problems. Chipset is identified in dmesg as NEC uPD 9210 USB controller. Current protection and limiting is completely up to the card designer. The best that FreeBSD can do is getting informed if the card design allows it, but I almost never saw a card doing this. Many cards just have some kind of self healing or melting fuses, some very bad designed cards don't even have this. Either your hubs really use more power then it is allowed to or you have a broken controller card. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
PCI bridges interrupts
[ Too advanced for -questions? Trying again. ]
I'm having a strange problem with interrupts, PCI bridges, and
FreeBSD 4-STABLE (cvsupped from a few months ago).
The motherboard is a Supermicro X5DL8-GG, dual-Xeon capable (only one is
populated). The BIOS is AMIBIOS 7.00.00. The BIOS settings have PnP OS
set to NO, ACPI OS is YES ('cause FreeBSD-CURRENT was once installed),
and power management is all disabled.
The company I'm working for has a rather complex PCI board that is
much larger than a normal card, and has its own power. The board can
be plugged directly into a slot in the motherboard, but for physical
and electrical (PCI 66) reasons wants to be attached via a bridge
riser card that we have also developed.
Everything on the board works when directly connected to the host,
except that we can't go 66MHz and we can't close the case. With
the riser card, *almost* everything works, except for interrupts.
I can see the interrupt line low *on the card edge connector on
the motherboard*, but it's not acknowledged, and our driver's ISR
doesn't run. We've throttled the riser card to 33MHz to eliminate
that possibility.
What follows is the verbose dmesg from the boot up without the
riser (bridge), followed by diffs when booted with the riser.
I'm looking for clues. It's about that far from working right,
and this almost looks like a FreeBSD issue.
Buddy, can you spare a clue? Why isn't the ISR running?
- - - 8 - - - dmesg.without-bridge
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 4.8-STABLE #35: Fri Aug 22 16:16:01 PDT 2003
[EMAIL PROTECTED]:/usr/src/sys/compile/CATP
Calibrating clock(s) ... TSC clock: 2399054672 Hz, i8254 clock: 1193051 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz
CLK_USE_TSC_CALIBRATION not specified - using old calibration method
CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU)
Origin = GenuineIntel Id = 0xf27 Stepping = 7
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
real memory = 1073676288 (1048512K bytes)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x005ac000 - 0x3ffe7fff, 1067696128 bytes (260668 pages)
avail memory = 1038774272 (1014428K bytes)
bios32: Found BIOS32 Service Directory header at 0xc00fdb20
bios32: Entry = 0xfdb30 (c00fdb30) Rev = 0 Len = 1
pcibios: PCI BIOS entry at 0xdb51
pnpbios: Found PnP BIOS data at 0xc00f4280
pnpbios: Entry = f:32c4 Rev = 1.0
Other BIOS signatures found:
ACPI: 000ff900
Preloaded elf kernel kernel at 0xc0585000.
Pentium Pro MTRR support enabled
Creating DISK md0
md0: Malloc disk
Math emulator present
pci_open(1):mode 1 addr port (0x0cf8) is 0x80041900
pci_open(1a): mode1res=0x8000 (0x8000)
pci_cfgcheck: device 0 [class=06] [hdr=80] is there (id=00141166)
Using $PIR table, 11 entries at 0xc00f4880
pcib-: pcib0 exists, using next available unit number
pcib-: pcib0 exists, using next available unit number
pcib-: pcib0 exists, using next available unit number
pcib-: pcib1 exists, using next available unit number
pcib-: pcib2 exists, using next available unit number
pcib-: pcib3 exists, using next available unit number
pcib-: pcib4 exists, using next available unit number
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Host to PCI bridge on motherboard
found- vendor=0x1166, dev=0x0014, revid=0x31
class=06-00-00, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
found- vendor=0x1166, dev=0x0014, revid=0x00
class=06-00-00, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
found- vendor=0x1166, dev=0x0014, revid=0x00
class=06-00-00, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
found- vendor=0x1002, dev=0x4752, revid=0x27
class=03-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=0
map[10]: type 1, range 32, base fd00, size 24
map[14]: type 1, range 32, base 8800, size 8
map[18]: type 1, range 32, base fe5ff000, size 12
found- vendor=0x8086, dev=0x100e, revid=0x02
class=02-00-00, hdrtype=0x00, mfdev=0
subordinatebus=0secondarybus=0
intpin=a, irq=9
map[10]: type 1, range 32, base fe5a, size 17
map[18]: type 1, range 32, base 8400, size 6
found- vendor=0x1166, dev=0x0201, revid=0x93
class=06-01-00, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
found- vendor=0x1166, dev=0x0212, revid=0x93
class=01-01-8a, hdrtype=0x00, mfdev=1
subordinatebus=0secondarybus=0
map[10]: type 1, range 32, base 01f0, size 3
map[14]: type 1, range 32,
RE: PCI bridges interrupts
On 24-Sep-2003 Steve Watt wrote:
[ Too advanced for -questions? Trying again. ]
I'm having a strange problem with interrupts, PCI bridges, and
FreeBSD 4-STABLE (cvsupped from a few months ago).
The motherboard is a Supermicro X5DL8-GG, dual-Xeon capable (only one is
populated). The BIOS is AMIBIOS 7.00.00. The BIOS settings have PnP OS
set to NO, ACPI OS is YES ('cause FreeBSD-CURRENT was once installed),
and power management is all disabled.
Turn ACPI off, there's a slim chance it might help.
Everything on the board works when directly connected to the host,
except that we can't go 66MHz and we can't close the case. With
the riser card, *almost* everything works, except for interrupts.
I can see the interrupt line low *on the card edge connector on
the motherboard*, but it's not acknowledged, and our driver's ISR
doesn't run. We've throttled the riser card to 33MHz to eliminate
that possibility.
What follows is the verbose dmesg from the boot up without the
riser (bridge), followed by diffs when booted with the riser.
I'm looking for clues. It's about that far from working right,
and this almost looks like a FreeBSD issue.
Buddy, can you spare a clue? Why isn't the ISR running?
Have you tried 5.x? Basically, 4.x doesn't really have all the
infrastructure to route interrupts, and if your BIOS screws it up,
then you aren't going to get the right IRQ number hooked up.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI bridges interrupts
On Wed, 24 Sep 2003, Steve Watt wrote: Buddy, can you spare a clue? Why isn't the ISR running? Check the PCI interrupt routing. A. -- Aaro Koskinen E-mail: [EMAIL PROTECTED]I'm the ocean, I'm the giant undertow. http://www.iki.fi/aaro ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
BUS DMA sync
Hi, I try to understand the purpose of the PRE sync (BUS_DMASYNC_PREREAD, BUS_DMASYNC_PREWRITE). I understand POST synchronization (BUS_DMASYNC_POSTREAD, BUS_DMASYNC_POSTWRITE) when a device to memory or a memory to device transfert needs to be synchronized. However, what does a synchronization before a transfert mean ? Regards, Vincent ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI bridges interrupts
You might want to make sure that you have an up to date stable. There was a fix to the PCI bridge interrupt swizzle. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BUS DMA sync
Vincent Jardin wrote: Hi, I try to understand the purpose of the PRE sync (BUS_DMASYNC_PREREAD, BUS_DMASYNC_PREWRITE). I understand POST synchronization (BUS_DMASYNC_POSTREAD, BUS_DMASYNC_POSTWRITE) when a device to memory or a memory to device transfert needs to be synchronized. However, what does a synchronization before a transfert mean ? With common architectures where FreeBSD runs on, only BUS_DMASYNC_PREWRITE and BUS_DMASYNC_POSTREAD are actually meaningful and needed. It's good style to use the two others where appriopriate though, because some more exotic architecture might require it some day. BUS_DMASYNC_PREWRITE is used to synchronize before there's a DMA tranfer from host memory to a device. It's needed to ensure the device will read up-to-date memory, because recent changes to memory might still sit in a cache, so it actually flushes the memory cache. BUS_DMASYNC_POSTREAD is used to synchronize after a DMA transfer from the device to host memory. It's needed to ensure the software will get up-to-date memory as written by the device, and not outdated memory sitting in a cache, so it actually invalidates the memory cache. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: PCI bridges interrupts
On Sep 24, 16:38, John Baldwin wrote:
} Subject: RE: PCI bridges interrupts
}
} On 24-Sep-2003 Steve Watt wrote:
} [ Too advanced for -questions? Trying again. ]
}
} I'm having a strange problem with interrupts, PCI bridges, and
} FreeBSD 4-STABLE (cvsupped from a few months ago).
}
} The motherboard is a Supermicro X5DL8-GG, dual-Xeon capable (only one is
} populated). The BIOS is AMIBIOS 7.00.00. The BIOS settings have PnP OS
} set to NO, ACPI OS is YES ('cause FreeBSD-CURRENT was once installed),
} and power management is all disabled.
}
} Turn ACPI off, there's a slim chance it might help.
No joy, I'm afraid.
} Everything on the board works when directly connected to the host,
} except that we can't go 66MHz and we can't close the case. With
} the riser card, *almost* everything works, except for interrupts.
} I can see the interrupt line low *on the card edge connector on
} the motherboard*, but it's not acknowledged, and our driver's ISR
} doesn't run. We've throttled the riser card to 33MHz to eliminate
} that possibility.
And if I were clever, I would've mentioned that it's in the
same slot. And the IRQ that gets assigned (by reading the
dmesg, as well as reading out the register from config space)
is the same.
} What follows is the verbose dmesg from the boot up without the
} riser (bridge), followed by diffs when booted with the riser.
}
} I'm looking for clues. It's about that far from working right,
} and this almost looks like a FreeBSD issue.
}
} Buddy, can you spare a clue? Why isn't the ISR running?
}
} Have you tried 5.x? Basically, 4.x doesn't really have all the
} infrastructure to route interrupts, and if your BIOS screws it up,
} then you aren't going to get the right IRQ number hooked up.
If the BIOS is screwing it up, it's somehow in the configuration
of the interrupt controller, which I thought was completely
owned by the OS.
I'd love to migrate it to 5.x, but there are bits of the driver
that have a rather intimate knowledge of other areas of the kernel
that are somewhat painful to drag forward. Management wants me
to try it on Linux, where the next gen of our driver is being
brought up.
But that's yet another OS install, and I'm (aren't we all?) in a
bit of a hurry.
Thanks,
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9
Internet: steve @ Watt.COM Whois: SW32
Free time? There's no such thing. It just comes in varying prices...
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BUS DMA sync
Thanks, What's about PREREAD ? What kind of CPU synchronization is required prior a DMA read ? There is no cache during a device to host memory process, isn't it ? Vincent Le Mercredi 24 Septembre 2003 23:54, Maxime Henrion a écrit : Vincent Jardin wrote: Hi, I try to understand the purpose of the PRE sync (BUS_DMASYNC_PREREAD, BUS_DMASYNC_PREWRITE). I understand POST synchronization (BUS_DMASYNC_POSTREAD, BUS_DMASYNC_POSTWRITE) when a device to memory or a memory to device transfert needs to be synchronized. However, what does a synchronization before a transfert mean ? With common architectures where FreeBSD runs on, only BUS_DMASYNC_PREWRITE and BUS_DMASYNC_POSTREAD are actually meaningful and needed. It's good style to use the two others where appriopriate though, because some more exotic architecture might require it some day. BUS_DMASYNC_PREWRITE is used to synchronize before there's a DMA tranfer from host memory to a device. It's needed to ensure the device will read up-to-date memory, because recent changes to memory might still sit in a cache, so it actually flushes the memory cache. BUS_DMASYNC_POSTREAD is used to synchronize after a DMA transfer from the device to host memory. It's needed to ensure the software will get up-to-date memory as written by the device, and not outdated memory sitting in a cache, so it actually invalidates the memory cache. Cheers, Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: PCI bridges interrupts
On 24-Sep-2003 Steve Watt wrote: On Sep 24, 16:38, John Baldwin wrote: } Subject: RE: PCI bridges interrupts And if I were clever, I would've mentioned that it's in the same slot. And the IRQ that gets assigned (by reading the dmesg, as well as reading out the register from config space) is the same. Across bridges the interrupts get swizzled sort of. Which means that device 0,4,8,etc. INT A gets mapped to INT A on the front side of the bridge, device 1,5,7,etc. INT A gets mapped to INT B. etc. IIRC your device is at device 5.0, so it's INT A should be mapped to INT B of that slot, which should get a different interrupt. } What follows is the verbose dmesg from the boot up without the } riser (bridge), followed by diffs when booted with the riser. } } I'm looking for clues. It's about that far from working right, } and this almost looks like a FreeBSD issue. } } Buddy, can you spare a clue? Why isn't the ISR running? } } Have you tried 5.x? Basically, 4.x doesn't really have all the } infrastructure to route interrupts, and if your BIOS screws it up, } then you aren't going to get the right IRQ number hooked up. If the BIOS is screwing it up, it's somehow in the configuration of the interrupt controller, which I thought was completely owned by the OS. No, the BIOS sets it up and we may try to tweak it. In 5.x we fully tweak it now, but 4.x still relies on the BIOS to set this up. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCI bridges interrupts
On 24-Sep-2003 M. Warner Losh wrote: You might want to make sure that you have an up to date stable. There was a fix to the PCI bridge interrupt swizzle. Ah yes, that's true. However, it doesn't seem that his interrupt is being routed, but I could be wrong. Also, there is another bug in the $PIR handling that I committed at BSDCon that also might fix the problem. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
VIA EPIA-M10000 board just works with FreeBSD 4.8
For anyone who's interested, I've been running FreeBSD 4.8 on the EPIA-1M mini-ITX for at least a couple months now; it's available for as little as $160 with CPU + motherboard + case + p/s bought integrated as the FIC Falcon CR53, and there's a surprising amount of I/O integrated onboard. For anybody who's looking to build cheap but reasonably powerful servers or desktop machines, this looks like a winner. I haven't run any real benchmarks, but in terms of feel it might be equivalent to maybe a 500-600MHz PIII. The total server parts list ran about $350 with shipping, including 7200rpm IDE drive and a 2nd 100BT card (Linksys LNE100TX.) I haven't tried X or the sound capabilities so I'm not sure how suitable it would be for a desktop; I also haven't tested whether the IEEE-1394 would work under FreeBSD. For a low-end server, though, it's pretty nice, and moderately quiet too. The motherboard includes integrated CPU, 1 DDR slot, 4 USB, 2 serial, 1 parallel I/O, 2 IEEE-1394, floppy port, dual IDE, SVGA out + SVHS TV out, 10/100 LAN, and 1 PCI. The IDE interface works at ATA133 under FreeBSD 4.8; the VIA/Realtek ethernet is recognized as vr0. The CPU integrated on the motherboard is a 1GHz VIA C3, an IDT descendant - the newer Nehemiah core which is claimed to have better instructions per clock than the older VIA cores. Matt Dillon posted about the earlier EPIA boards a while back, so I thought I'd add a note that this one also works well. -- Clifton, not a VIA salesrep -- Clifton Royston -- LavaNet Systems Architect -- [EMAIL PROTECTED] Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: PCI bridges interrupts
On Sep 24, 18:17, John Baldwin wrote: } Subject: RE: PCI bridges interrupts } } On 24-Sep-2003 Steve Watt wrote: } On Sep 24, 16:38, John Baldwin wrote: } } Subject: RE: PCI bridges interrupts } } And if I were clever, I would've mentioned that it's in the } same slot. And the IRQ that gets assigned (by reading the } dmesg, as well as reading out the register from config space) } is the same. } } Across bridges the interrupts get swizzled sort of. Which means } that device 0,4,8,etc. INT A gets mapped to INT A on the front } side of the bridge, device 1,5,7,etc. INT A gets mapped to INT B. } etc. IIRC your device is at device 5.0, so it's INT A should be } mapped to INT B of that slot, which should get a different interrupt. It's at 2.0 when plugged directly in, and 6.0 when on the bridge, which seems like the same swizzle target. Oh, wait, the bus number goes into the swizzle equation too, doesn't it? Hmm. I wonder if turning on APIC_IO would help. } } What follows is the verbose dmesg from the boot up without the } } riser (bridge), followed by diffs when booted with the riser. } } } } I'm looking for clues. It's about that far from working right, } } and this almost looks like a FreeBSD issue. } } } } Buddy, can you spare a clue? Why isn't the ISR running? } } } } Have you tried 5.x? Basically, 4.x doesn't really have all the } } infrastructure to route interrupts, and if your BIOS screws it up, } } then you aren't going to get the right IRQ number hooked up. } } If the BIOS is screwing it up, it's somehow in the configuration } of the interrupt controller, which I thought was completely } owned by the OS. } } No, the BIOS sets it up and we may try to tweak it. In 5.x we } fully tweak it now, but 4.x still relies on the BIOS to set this } up. OK. Last time I looked closely at the PC architecture, it was a '386 and things were simple. On Sep 24, 18:17, John Baldwin wrote: } Subject: Re: PCI bridges interrupts } } On 24-Sep-2003 M. Warner Losh wrote: } You might want to make sure that you have an up to date stable. There } was a fix to the PCI bridge interrupt swizzle. } } Ah yes, that's true. However, it doesn't seem that his interrupt is } being routed, but I could be wrong. Also, there is another bug in the } $PIR handling that I committed at BSDCon that also might fix the } problem. Was that committed to 4-STABLE? If so, I'll be getting it momentarily. Thanks! -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SimpleTech USB HDD driver
On Tue, Sep 23, 2003 at 08:33:15AM +0200, Devon H. O'Dell wrote: Scott Mitchell wrote: This is fine - just an informational message rather than anything actually wrong. Out of curiosity, what does that indicate (or where can I find comments in the source)? As I understand it, the USB mass storage protocol uses SCSI commands, which is why you end up mounting /dev/da0 to see your drive. For reasons I'm not familiar with, there are two flavours of these SCSI commands around - 6 byte and 10 byte. I believe the driver always tries to use 6 byte commands first and falls back to 10 byte if the shorter commands are not supported. You used to need a quirk entry for such devices (to force the driver to only use 10 byte commands) but things have improved to the point that quirks are now only needed for really screwed up devices. No idea why both 6 byte and 10 byte commands exist. No doubt someone out there knows the historical background to it all. Yes, I also got an email from the product manager of the SimpleDrive asking me what sort of documentation I was looking for. This seems like an open-source friendly company; just so that we can keep this in mind in case there are portable storage device/hard drive issues in the future. It looks like Firewire is also taken care of, but you never know what else there might be in the future. That's good news. Cheers, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Any workarounds for Verisign .com/.net highjacking?
On Fri, Sep 19, 2003 at 12:09:22PM +0200, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2003-09-16 16:58:06 -0400: At 10:23 AM -1000 9/16/03, Clifton Royston wrote: In the meantime I'm trying to figure out if there's some simple hack to disregard these wildcard A records, short of requesting zone transfers of the root nameservers (e.g. via peering with f.root-servers.net) and purging those records out of the zone before loading it. Any ideas, either under djbdns or Bind 9? The story at http://daily.daemonnews.org/view_story.php3?story_id=4068 notes that there is a patch for dnscache at: http://tinydns.org/djbdns-1.05-ignoreip.patch see this one: http://tinydns.org/djbdns-1.05-ignoreip2.patch and this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/56951 I have no idea of how well either of these work. Use your own discretion at applying them. djbdns-1.05-ignoreip2.patch seems to work very well here, on three boxes; fourth one will follow later today. Belated followup to this: The above-mentioned DJBDNS patch has been working great for me. I worked it into my local copy of the ports tree. Things are much better now... -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] Tiki Technologies Lead Programmer/Software Architect Did you ever fly a kite in bed? Did you ever walk with ten cats on your head? Did you ever milk this kind of cow? Well we can do it. We know how. If you never did, you should. These things are fun, and fun is good. -- Dr. Seuss ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Call for bi-monthly status reports
All, After a long hiatus, Robert Watson and I would like to start up the bi-monthly status reports again. As before, the template is at http://www.freebsd.org/news/status/report-sample.xml, with submissions going to [EMAIL PROTECTED] While this report is primarily for projects that are in-progress, we would also encourage submissions for projects that are still in their idea and planning phases. We are hoping for a large turnout, and are especially looking for status from the following areas: - ia64 - sparc64 - amd64 - KSE - XFS - SMPng locking and infrastructure - power management Submissions are due to [EMAIL PROTECTED] by Oct 1. Thanks! Scott Long Robert Watson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
