silly gcc bug in RELENG_6
test.c:
typedef struct a astruct;
void
foobar(void)
{
int s = sizeof(astruct);
}
gcc test.c
test.c: In function `foobar':
test.c:6: error: invalid application of `sizeof' to incomplete type
`test.c'
Looks like someone goofed up some printf() args.
gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.4 [FreeBSD] 20050518
- Brian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Display files currently in the buffer cache
Robert Watson wrote: On Mon, 31 Oct 2005, Scott Long wrote: Assuming not, is it feasible to write one to do this? (if so, any pointers appreciated - massive FreeBSD internals newbie here). This would be a cool tool! I've been thinking of that too, and also would like to have a lkdump tool - which dumps information about currently locked files. Does the FreeBSD VM really have a concept of filenames at all? I thought that all it understood was buffer objects and vnodes. And since there isn't a strong correlation between vnodes and the filesystem namespace, it would be hard to provide such information. The usual work-arounds are either to assume this explicitly, showing device numbers and inodes, or to give it a best effort shot (use the name cache). Either way, the results are still likely to be useful. You'll get some obvious messes, such as the results of installworld deleting old libraries and running processes continuing to use the deleted ones, resulting in an inode number that doesn't have a name that can be found. The same approach is taken in lsof, whereby "good enough" is generally good enough. The problems start when assumptions are made that paths can always be found. Yeah - this is what I had in mind. The application is this: I want to be able to show files and pages that a database (Postgres in this case) has cached. So a list of inodes and pages (or page offsets) is fine, as I can pass these to the (postgres) specific part of the utility and it can figure out which inodes correspond to its own files. Maybe the name cache lookup will be good enough for me... Ok, so, ahem, if I were to start on this, what bits of the src should I delve into first? Any other newbie pointers will also be much appreciated :-). (Was meaning to start this yesterday, but got sidetracked with a Promise SX4060 that I can't get to work...). Cheers Mark ___ 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/6/7 kernel emulator for NetBSD 2.x
On Saturday 29 October 2005 06:59 am, Rui Paulo wrote: > On 2005.10.29 00:01:42 -0600, M. Warner Losh wrote: > | In message: <[EMAIL PROTECTED]> > | > | Rui Paulo <[EMAIL PROTECTED]> writes: > | : On 2005.10.26 10:22:52 -0700, Bill Studenmund wrote: > | : | On Mon, Oct 24, 2005 at 10:35:47PM +0200, Hans Petter Selasky wrote: > | : | > Main features: > | : | > > | : | > - Implements FreeBSD's devfs on NetBSD. > | : | > | : | In the past, we (NetBSD folks) have talked about a devfs. One issue > | : | that has come up (I'll be honest, I've raised it a lot) is a desire > | : | to retain permission changes across boots, and to tie devices (when > | : | possible) to a device-specific attribute rather than a probe order. > | : | > | : | Does FreeBSD's devfs support locators and persistent information? Are > | : | there plans to support something like that, if not? > | : > | : I remember Linux's devfs having a configure file for that particular > | : objective. The user would set the permission flags in (I can't recall > | : if this is the real name) /etc/devfsd.conf and let devfsd do the job. > | : > | : You could also use another directory for permissions, like /dev-state, > | : but personally, I don't like this method. > | : > | : http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html#persistenc > | :e > | > | FreeBSD also has a file that can be used to control the permissions > | and ownerships at runtime. The persistance can be there, but isn't > | there by default like the old nodes in /dev. > > The other problem I see here is how devfs works in single user mode > where devfsd is not started and no permissions are set. How does > FreeBSD solve this problem? Well, for one thing you generally are root in single user mode such that permissions on /dev aren't quite as important as multi-user. :) However, the devfs rulesets are managed in the kernel, and there isn't a userland devfsd, so you could always manually set or load the devfs rules you want to apply while you are in single user. I think the biggest thing to think about is that devfs makes you think about /dev differently. It's more of a true psuedo-filesystem where there aren't actual files representing devices like the special device nodes that mapped to specfs. It's more like procfs. Do you ty to solve the problem of persistent permissions for files in /proc? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Display files currently in the buffer cache
On Mon, 31 Oct 2005, Scott Long wrote: Assuming not, is it feasible to write one to do this? (if so, any pointers appreciated - massive FreeBSD internals newbie here). This would be a cool tool! I've been thinking of that too, and also would like to have a lkdump tool - which dumps information about currently locked files. Does the FreeBSD VM really have a concept of filenames at all? I thought that all it understood was buffer objects and vnodes. And since there isn't a strong correlation between vnodes and the filesystem namespace, it would be hard to provide such information. The usual work-arounds are either to assume this explicitly, showing device numbers and inodes, or to give it a best effort shot (use the name cache). Either way, the results are still likely to be useful. You'll get some obvious messes, such as the results of installworld deleting old libraries and running processes continuing to use the deleted ones, resulting in an inode number that doesn't have a name that can be found. The same approach is taken in lsof, whereby "good enough" is generally good enough. The problems start when assumptions are made that paths can always be found. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Display files currently in the buffer cache
Eric Anderson wrote: Mark Kirkwood wrote: Dear hackers, I'm interested in being able to display some data about the contents of the buffer cache , say file name and page offset (something like IRIX's 'bufview'). Is there any utilities that do this currently? (searched around but didn't see anything in ports). Assuming not, is it feasible to write one to do this? (if so, any pointers appreciated - massive FreeBSD internals newbie here). This would be a cool tool! I've been thinking of that too, and also would like to have a lkdump tool - which dumps information about currently locked files. Eric Does the FreeBSD VM really have a concept of filenames at all? I thought that all it understood was buffer objects and vnodes. And since there isn't a strong correlation between vnodes and the filesystem namespace, it would be hard to provide such information. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Display files currently in the buffer cache
Mark Kirkwood wrote: Dear hackers, I'm interested in being able to display some data about the contents of the buffer cache , say file name and page offset (something like IRIX's 'bufview'). Is there any utilities that do this currently? (searched around but didn't see anything in ports). Assuming not, is it feasible to write one to do this? (if so, any pointers appreciated - massive FreeBSD internals newbie here). This would be a cool tool! I've been thinking of that too, and also would like to have a lkdump tool - which dumps information about currently locked files. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Native ATAPI MO driver
On Monday 24 October 2005 11:27, Søren Schmidt wrote: > On 24/10/2005, at 3:49, Jason Harmening wrote: > > Hi, > > > > I have a 2.3G Fujitsu MO drive, and I've gotten tired of using > > atapicam to > > access it. I'm thinking of writing a native ATAPI driver that > > could be added > > to the kernel through a configuration line like: > > > > device atapimo > > > > I've been doing a little work to see how feasible this is--the > > kernel already > > defines the ATA_ATAPI_TYPE_OPTICAL device type that is received > > from my drive > > during probing. But ATA_ATAPI_TYPE_OPTICAL isn't actually used > > anywhere, and > > there is no driver that can actually recognize and attach to an > > ATAPI MO > > drive. > > > > I modified the atapifd driver (src/sys/dev/ata/atapi-fd.c) to also > > recognize > > ATA_ATAPI_TYPE_OPTICAL, and my drive was actually recognized during > > probing > > as afd0, but afd_attach returned an error. It looks as if afd_sense > > () was > > failing, which I'm guessing is because ATAPI MO drives (or mine, at > > least) > > use a different capabilities page code and/or capabilities page > > structure > > than ATAPI floppies. The atapi-fd driver uses 0x5 for its > > "Capabilities and > > Mechanical Status" page code, while everything else (atapi-cd, > > atapi-tape) > > uses 0x2a. All three drivers have distinctly different structures > > for this > > page. > > > > So I'm wondering: do ATAPI MO drives use a capabilities page code/ > > structure > > more like CD/DVD drives, or do they have their own unique ATAPI page > > structure? If so, where can I find a document outlining the > > structure? > > > > I've found loads of documents detailing the page structure for CD/ > > DVD drives, > > but nothing for MO drives (or floppies or tape drives for that > > matter). > > > > Also, beyond the capabilities page, are there any other special > > considerations > > I'd need to make for an MO driver? > > I did plan to write such a driver back when, but HW seemed to have > disappeared from all the vendors I've asked so it was pu ton the > backburner. > Anyhow I should have the docs somewhere so it should be possible to > get this working... > > Søren Schmidt > [EMAIL PROTECTED] I finally managed to find some documentation from Fujitsu, and it turns out my drive (and older Fujitsu MO drives as well) use exactly the same capabilities page and page code that are already defined in atapi-fd.h. The reason my drive was failing afd_sense() was that by default it returns an 8-byte block descriptor between the header and the actual page. But there's a Disable Block Descriptor bit at byte1, bit3 of the MODE SENSE command that will prevent it from doing this if set. It looks like the ATAPI floppies and earlier MO drives just ignored this bit and never returned the block descriptor. So I just changed the second character in the command array in afd_sense() from 0 to 8, added ATA_ATAPI_TYPE_OPTICAL to afd_probe(), and the drive now works as afd0. From what I've seen, the DBD bit seems to be a standard part of the MODE SENSE command block, so I don't think having it set will mess with any of the other drives supported by atapifd. Reading, writing, deleting, prevent/allow eject, and newfs (UFS2) all work with the drive as afd0--haven't tried anything else yet. Jason Harmening ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp services (ssh,ftp) does not work
Le 30/10/2005 à 02:07:49-0800, kamal kc a écrit > dear all, > > i have put sshd_enable="YES" > and inetd_enable="YES" > in /etc/rc.conf. > > netstat -an also shows that the port numbers > 21 and 22 are in listen state > > ftp is uncommented in /etc/inetd.conf > > but still the ssh/ftp services does not work. > > when i ftp from another computer the netstat > shows connection established but the ftp client > does not show anything. > > using ftp/ssh on the same computer also does not show > anything --- just blank. > > > what could have gone wrong. Check your /etc/hosts.allow Regards. -- Albert SHIH Universite de Paris 7 (Denis DIDEROT) U.F.R. de Mathematiques. Heure local/Local time: Sun Oct 30 16:15:08 CET 2005 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel crash dump could not be obtained
dear all, i have to make modifictions to the kernel and i have been encountering kernel crashes all the time. the kernel panics with messages starting with vm_fault: and then crashes and reboots. i guess i have done incorrect memory operations and i want to know where i went wrong. so i thought of obtaining the crash dump. i went through the developers guide. and i added the following lines on the /etc/rc.conf --- dumpdev="/dev/ad0s1b" dumpdir="/var/crash" savecore_flags="" -- the /etc/fstab file is Device Mountpoint FStype Options DumpPass# /dev/ad0s1b noneswapsw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1e /tmpufs rw 2 2 /dev/ad0s1f /usrufs rw 2 2 /dev/ad0s1d /varufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 swap partition is /dev/ad0s1b swapinfo gives the output:-- Device 1K-blocks UsedAvail Capacity /dev/ad0s1b4950480 495048 0% My memory size according to dmesg is -- real memory = 266600448 (254 MB) avail memory = 251232256 (239 MB) -- Now when the kernel crashes it prints the message writing dump 240MB but rebooting does not show any crash dump file on /var/crash. please help kamal __ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
