Re: How can I fake a device ?
[EMAIL PROTECTED] wrote:
In message <[EMAIL PROTECTED]>, Iasen Kostov wrote:
Hi,
I want to know is there a way to call *_probe (for device driver) with
fake (PCI) device that does not exists in the system ?
First of all a cant find how "struct device" is declared (i've searched
even the compile/ dir) and second I think that I'll need to intercept
pci_get_vendor and pci_get_device funcs with my own which should detect
the fake device and thus will return vandor/device that I need to fake.
I realy don't need anything else except _probe ...
I have never tried such but grimpsed the PCI framework,
I propose the following, though I don't imagine why you want
to do so:
Your driver have to contain DEVICE_IDENTIFY method
that calls device_add_child to allocate device_t object.
Then you allocate 'struct pci_devinfo' and initialize
pci_devinfo as you like. And you have to make your
driver as a module. Then a device object will show up on
the device tree on your system.
You may want to have a look at pci_add_children@/sys/dev/pci/pci.c
I think I was not clear .. .sorry. I ment to lie the driver that some
device (that is not realy plugged in the machine) exists. Doing so I can
check if drivers _probe() func returns "OK"
or not and by checking every device from /usr/share/misc/pci_vendors I
could build device<->driver_file database.
I've patched a bit /sys/dev/pci/pci.c like this:
typedef uintptr_t *pci_fake_read_ivars_t(pcicfgregs *cfg);
static pci_fake_read_ivars_t *pci_fake_read_ivars = NULL;
int
pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pci_devinfo *dinfo;
pcicfgregs *cfg = NULL;
if(pci_fake_read_ivars && !strcmp("fake0", dev->nameunit)) {
(*pci_fake_read_ivars)(cfg);
} else {
dinfo = device_get_ivars(child);
cfg = &dinfo->cfg;
}
And when I load my module it will set pci_fake_read_ivars and will start
to test drivers probe sending devices with nameunit set to "fake0" thus
telling pci_read_ivar() to fake the return values by calling
pci_fake_read_ivars() callback ... I think this is very messy ... I hope
that it will work this way :)
regards
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How can I fake a device ?
In message <[EMAIL PROTECTED]>, Iasen Kostov wrote:
>>> Hi,
>>>I want to know is there a way to call *_probe (for device driver) with
>>>fake (PCI) device that does not exists in the system ?
>>>First of all a cant find how "struct device" is declared (i've searched
>>>even the compile/ dir) and second I think that I'll need to intercept
>>>pci_get_vendor and pci_get_device funcs with my own which should detect
>>>the fake device and thus will return vandor/device that I need to fake.
>>>I realy don't need anything else except _probe ...
>>>
>>>
>>
>>I have never tried such but grimpsed the PCI framework,
>>I propose the following, though I don't imagine why you want
>>to do so:
>>
>>Your driver have to contain DEVICE_IDENTIFY method
>>that calls device_add_child to allocate device_t object.
>>Then you allocate 'struct pci_devinfo' and initialize
>>pci_devinfo as you like. And you have to make your
>>driver as a module. Then a device object will show up on
>>the device tree on your system.
>>
>>You may want to have a look at pci_add_children@/sys/dev/pci/pci.c
>>
>>
>>
>I think I was not clear .. .sorry. I ment to lie the driver that some
>device (that is not realy plugged in the machine) exists. Doing so I can
>check if drivers _probe() func returns "OK"
>or not and by checking every device from /usr/share/misc/pci_vendors I
>could build device<->driver_file database.
Hmm, do you want to implement docking station or something?
This is a part of my interest.
>I've patched a bit /sys/dev/pci/pci.c like this:
>
>typedef uintptr_t *pci_fake_read_ivars_t(pcicfgregs *cfg);
>static pci_fake_read_ivars_t *pci_fake_read_ivars = NULL;
>
>int
>pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
>{
>struct pci_devinfo *dinfo;
>pcicfgregs *cfg = NULL;
>
>if(pci_fake_read_ivars && !strcmp("fake0", dev->nameunit)) {
>(*pci_fake_read_ivars)(cfg);
>} else {
>dinfo = device_get_ivars(child);
>cfg = &dinfo->cfg;
>}
>
>And when I load my module it will set pci_fake_read_ivars and will start
>to test drivers probe sending devices with nameunit set to "fake0" thus
>telling pci_read_ivar() to fake the return values by calling
>pci_fake_read_ivars() callback ... I think this is very messy ... I hope
>that it will work this way :)
pci_read_ivar itself will not access real hardware: cache its value and
simply use hardware register index as ivar index.
So it is enough to initialize
struct pci_devinfo then call device_set_ivar. Rather, there may be problem
when pci_cfg_save()@sys/dev/pci/pci.c is called.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How can I fake a device ?
[EMAIL PROTECTED] wrote:
In message <[EMAIL PROTECTED]>, Iasen Kostov wrote:
Hi,
I want to know is there a way to call *_probe (for device driver) with
fake (PCI) device that does not exists in the system ?
First of all a cant find how "struct device" is declared (i've searched
even the compile/ dir) and second I think that I'll need to intercept
pci_get_vendor and pci_get_device funcs with my own which should detect
the fake device and thus will return vandor/device that I need to fake.
I realy don't need anything else except _probe ...
I have never tried such but grimpsed the PCI framework,
I propose the following, though I don't imagine why you want
to do so:
Your driver have to contain DEVICE_IDENTIFY method
that calls device_add_child to allocate device_t object.
Then you allocate 'struct pci_devinfo' and initialize
pci_devinfo as you like. And you have to make your
driver as a module. Then a device object will show up on
the device tree on your system.
You may want to have a look at pci_add_children@/sys/dev/pci/pci.c
I think I was not clear .. .sorry. I ment to lie the driver that some
device (that is not realy plugged in the machine) exists. Doing so I can
check if drivers _probe() func returns "OK"
or not and by checking every device from /usr/share/misc/pci_vendors I
could build device<->driver_file database.
Hmm, do you want to implement docking station or something?
This is a part of my interest.
Don't know what you mean whit "docking station". I want to create
framework for extracting info from every driver which device it can handle.
Then create create conf for devd or kernel_driver_autoloader :) or
something like that (e.g. windoze .inf database).
I've patched a bit /sys/dev/pci/pci.c like this:
typedef uintptr_t *pci_fake_read_ivars_t(pcicfgregs *cfg);
static pci_fake_read_ivars_t *pci_fake_read_ivars = NULL;
int
pci_read_ivar(device_t dev, device_t child, int which, uintptr_t *result)
{
struct pci_devinfo *dinfo;
pcicfgregs *cfg = NULL;
if(pci_fake_read_ivars && !strcmp("fake0", dev->nameunit)) {
(*pci_fake_read_ivars)(cfg);
} else {
dinfo = device_get_ivars(child);
cfg = &dinfo->cfg;
}
And when I load my module it will set pci_fake_read_ivars and will start
to test drivers probe sending devices with nameunit set to "fake0" thus
telling pci_read_ivar() to fake the return values by calling
pci_fake_read_ivars() callback ... I think this is very messy ... I hope
that it will work this way :)
pci_read_ivar itself will not access real hardware: cache its value and
simply use hardware register index as ivar index.
So it is enough to initialize
struct pci_devinfo then call device_set_ivar. Rather, there may be problem
when pci_cfg_save()@sys/dev/pci/pci.c is called.
Thank a lot this will realy simplify the work ! :) I won't need to patch
sys/dev/pci/pci.c this way. Thanks .
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: too late null checks
Andre Oppermann wrote: Did you run your entire tool on the FreeBSD tree or is this subset of the available tests and checks? It's a small sample of the larger whole. The whole thing isn't as interesting to look at yet, but I'm working on it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network Packet drops in FreeBSD 5.2.1
Anand Subramanian wrote: Hi All, I am using an Intel Celeron box (single CPU,1.7GHz, 495MB real and 472 MB avail memory, FreeBSD 5.2.1 #15 release), to run a daemon process which shares a circular queue/buffer with the kernel. The daemon drains objects off the front of the queue while the queue objects are populated by the protocol processing function say, XXX_input() in the kernel, called by ip_input(). If the front and rear indices of the shared buffer are equal then the protocol stack drops the packet alright. This model works fine for packet (60-64 bytes in size) input rates upto 11500 packets/sec, after which packets are lost. The machine running the daemon uses the SiS 900 NIC, 10/100Mbps. Try a nic that has hardware support for checksum and fragmentation offloading. If I'm not mistaken that sis900 is an integrated nic? It was somewhat flaky for me.. If you're operating at 100Mbps, your line rate doesn't become saturated at 12kpps. In fact, 100Mbps isn't saturated until around ~140kpps from my own lab results. The packet loss was detected using the "netstat -I sis0" command, run both on starting the daemon and upon shutting the daemon down. The Ipkts field in the netstat output should indicate the number of packets received by the interface in question.. With an appropriate chosen value for the shared buffer length, no packets are dropped because the shared queue is full. Hence packets seem to be dropped at the adapter level. The surprising part seems to be that though packets are being dropped/lost, top shows a ~70% idle system with peak interrupt time of ~25%. The daemon uses a "hacked" version of the select() call with a timeout value. The XXX_input() protocol processing function signals the thread/KSE waiting on the hacked select() call as soon as it sees that there are packets in the shared buffer(shared between the daemon and the kernel). Question is : 1. Is top really accurate in reporting all stats at such workloads, or input pkt rates? Can the %Idle time reported by top be trusted? I've seen some exceptions to the rule, yet overall it seems accurate - but I've never read the inter workings of top, so I'm no expert. 2. At increasing network input loads (12000 pkts/sec), much of the system time maybe spent in the hardware interrupt handler, ip processing functions. With the user daemon calling select(), any time spent in the select() call would be charged to the daemon's timeslice. Would it be fairly scheduled to run. It should be(of course depending on the RPLs), but wanted to confirm this. I'm not sure if it's just the NIC you're using, but you should probably enable device polling, perhaps even enable fastforwarding. 3. When ip_drain() is called and it calls the DEQUEUE macro, it acquires Giant. DOes this mean other netisr's and handlers are disabled so that the queue gets emptied in a sort of batch-mode behavior? 4. I am trying different clock speeds by changing kern.hz in loader.conf. Doesn't seem to help but I am still looking into this. When network packets are being dropped at the interface level, is it really necessary for the system to be ~0% idle??? I'm sure it's all interrupts, again a better NIC could help :> Any other input is greatly appreciated. Best, Anand HTH, -mpf ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[TEST] rewritten floppy driver
Please help test this rewrite of the floppy driver so it can qualify to get into 5.3. Can the PC98 coders please try to create a fdc_cbus.c so we can use the same driver on PC98 ? If anybody wants to play with 2.88M floppies, I belive I found at least one bug which would have prevented it from working with the old driver. If you get into trouble with this driver, please set: sysctl debug.fdc.debugflags=255 and recreate the problem, then send me the stuff it prints. Thanks! Poul-Henning phk 2004-08-20 15:14:25 UTC FreeBSD src repository Modified files: sys/sys fdcio.h usr.sbin/fdcontrol fdcontrol.c usr.sbin/fdformatfdformat.c usr.sbin/fdread fdutil.c sys/dev/fdc fdc.c fdc_acpi.c fdc_isa.c fdc_pccard.c fdcvar.h Log: Rewrite of the floppy driver to make it MPsafe & GEOM friendly: [...] -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
use after free bugs
these are results from running Coverity's analysis over Freebsd 4.10 kernel. two improper loops: if_ef.c:566 and atapi-all.c ng_socket.c: possible double free of resp 815 and 870, depending on caller context. is this possible? if_bfe.c: double call to bfe_release_resources will free lots of stuff twice on failure. aha_isa.c: aha_isa_attach: aha_free free "aha", can't use it afterwards, lots of examples. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
malloc null bugs
Found during analysis with Coverity's tools. FreeBSD 4.10 atapi-cd.c, everywhere. I understand there was some question of not being to deal with failure gracefully in ata, but many of these are in functions like ioctl which can easily report errors. igmp.c:find_rti mii.c:mii_phy_probe. device_add_child can also fail, and is not checked. pst-raid.c:pst_add_raid if_dc.c:dc_decode_leaf_mii if_ti:ti_setmulti if_sk.c:sk_vpd_read uipc_syscalls.c:sf_buf_init mpt.c:mpt_send_port_enable, mpt_get_request can fail if_wi_pci.c:attach, bus_alloc_resource may fail ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
off by one bounds
errors in freebsd 4.10 found by Coverity's analysis. awi_wep.c:awi_wep_setalgo, algo == sizeof svr4_signal.c:SVR4_NSIG one larger than TBLSIZ linprocfs_misc.c:linprocfs_doprocstatus, p_stat == sizeof ibcs2_msg.c:ibcs2_poll, fd == FD_SETSIZE if_ray.c:ray_rx_mgt_info, len == NWID_LEN ciss.c:ciss_cam_action_io, target == CISS_MAX_LOGICAL in6.c:in6_are_prefix_equal len == 128 in6.c:in6_prefixlen2mask, len == 128 ip_icmp.c:ip_next_mtu, i == sizeof, dir >= 0 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
