Re: kern/83807: [sis] [patch] if_sis: Wake On Lan support for FreeBSD
On Sat, Jun 09, 2007 at 11:08:01AM +0200, Edwin Mons wrote: Will this feature ever be incorporated in mainstream FreeBSD? I'm eagerly waiting for it to land in -CURRENT... I have no idea. I haven't got much feedback on this patch, apart from one or two people who sent me a quick thank you note :) So I have no idea how many people are actually using the patch. I know that: * if_sis and if_vr wake on lan support is very stable for me. I've been using this code for nearly 2 years now. * if_nve support has afaik never been tested (plus it's a binary blob driver and will apparently be replaced with OpenBSD's nfe driver soon.) I run a single 6.2 box here that I maintain the patch for. I'd be happy to setup a -current box to port the patch to -CURRENT. But I need to know whether it's worth doing the work. I'd like to get feedback on my patch by someone who is willing and able to help me get it into the tree. I need to know what needs to be done and/or changed to make the patch ready for mainline. There are some small bits in the patch that are incomplete, e.g. secure on password support. I've been thinking about simply dropping this feature because I consider it useless but ymmv. I'd also be happy to add WOL support for more chipsets. Adding support is relatively easy as long as another open source OS (e.g. Linux) supports wake on lan for a chipset and even easier if a good datasheet is available (as in case of if_sis). If anyone has a card that does wake on lan after shutdown from Linux but not after shutdown from FreeBSD with my patch applied let me know. You may need to use the ethtool utility to enable WOL on Linux. Cc'ing hackers@ in case someone there is interested in helping out. Kind regards, Edwin Mons -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpnZkvUQyfvv.pgp Description: PGP signature
a gdb patch for fbsd
Dear all, Following is a patch to current gdb support in FreeBSD. I think it is useful when FreeBSD is not going to upgrade its gdb to gdb 6.x. The patch settle the core dump problem of attach command without a object file: #gdb gdb attach http://www.vlakno.cz/~rdivacky/gdb.patch Thanks rdivacky @FreeBSD.org for encouraging me settle this bug. Sincerely Zhouyi Zhou ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD-6.2 PLIP - does it still work ?
Reference: From: ghozzy [EMAIL PROTECTED] Date: Fri, 8 Jun 2007 22:59:26 +0400 Message-id: [EMAIL PROTECTED] ghozzy wrote: On 6/8/07, Julian Stacey [EMAIL PROTECTED] wrote: Anyone seen PLIP working on FreeBSD-6.2 release ? I've tested my PLIP cable between 2 x 4.11 boxes. I'm trying to install a laptop with 6.2 boot flops (with failed pcmcia/ether recognition) I cant get that laptop a 6.2 tower to talk to each other. Neither will those 2 x 6.2 talk to 4.11. I havent quite done all exhaustive tests, (but am exhausted seems worth asking :-) Julian -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com HTML mail=spam. Ihr Rauch=mein allergischer Kopfschmerz. Dump cigs 4 snuff. It seems to me PLIP has been broken somwhere after branching RELENG_5. Between two RELENG_4 it worked fine (used from about 4.3 to latest 4.11). If any end was using RELENG_5 or RELENG_6 it didn't work any more. I thought first, maybe there were some incompatible changes in protocol or something, i tried to use the same FreeBSD versions on two ends (both RELENG_5 or both RELENG_6), but that was not the case. My tests were not exhaustive either, but i actually tried to fire it up again numerous times, enough for my own assurance. If anybody could shed some light, i would be curious. I could also make tests if needed. Thanks for confirmation ghozzy, Can anyone say eg No it works for me ? Or now we know PL-IP is broken, Options: - Post [EMAIL PROTECTED] for specialists, - Post [EMAIL PROTECTED] (where it most hurts, as PLIP really needed when pcmcia slots not recognised on older laptops so cant install FreeBSD). - Send-pr for manual to declare plip broken. - Read compare source of 4.11 6.2 Release src/sys/dev/ppbus/if_plip.c (interesting, but short of time, others who've hacked / broken it might fix quicker ?) I viewed with /usr/ports/textproc/mgdiff diff not that big, eg diff -c 4.11/usr/src/sys/dev/ppbus/if_plip.c.~1~ \ 6.1/usr/src/sys/dev/ppbus/if_plip.c.~1~ | wc 4811466 11651 Julian -- Julian Stacey. Munich Computer Consultant, BSD Unix C Linux. http://berklix.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/83807: [sis] [patch] if_sis: Wake On Lan support for FreeBSD
Stefan Sperling wrote: On Sat, Jun 09, 2007 at 11:08:01AM +0200, Edwin Mons wrote: Will this feature ever be incorporated in mainstream FreeBSD? I'm eagerly waiting for it to land in -CURRENT... I have no idea. I haven't got much feedback on this patch, apart from one or two people who sent me a quick thank you note :) So I have no idea how many people are actually using the patch. I know that: * if_sis and if_vr wake on lan support is very stable for me. I've been using this code for nearly 2 years now. * if_nve support has afaik never been tested (plus it's a binary blob driver and will apparently be replaced with OpenBSD's nfe driver soon.) I run a single 6.2 box here that I maintain the patch for. I'd be happy to setup a -current box to port the patch to -CURRENT. I currently have one -CURRENT machine, and several 6.2-STABLE machines. For at least two of them (the -CURRENT and an x86 -STABLE machine) I'd really like to have WoL support, as these are my workstation and a home server, both of them really do not need to be on all the time, but I want to be able to reach them when I need a file from them when I'm elsewhere. I'd also be happy to add WOL support for more chipsets. Adding support is relatively easy as long as another open source OS (e.g. Linux) supports wake on lan for a chipset and even easier if a good datasheet is available (as in case of if_sis). I usually use either if_em or if_xl chipsets, so I hoped landing this code in at least -CURRENT (should go there first, I guess) would result in more chipsets supported ;) If anyone has a card that does wake on lan after shutdown from Linux but not after shutdown from FreeBSD with my patch applied let me know. You may need to use the ethtool utility to enable WOL on Linux. I don't run Linux on either machine. Perhaps I could do some tests on my workstation with a CD-based linux distribution. Edwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
On Jun 9, 2007, at 9:22 AM, Ivan Voras wrote: Another thing that would be nice to have is support for fdisk and disklabel partitions inside geom_part, so it's management utility can be used for both GPT and old style partition management (instead of currently used two tools: fdisk and disklabel). I do have to make FreeBSD/ia64 boot on a rx2660, but after that I may be able to take a look at it. I know what's there and I know what's missing, so I should be able to get the partitioning stuff working soon-ish. The bootblock requirements may take little longer, because there's where g_part is missing features. Keep me in the loop. FYI, -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
On Jun 9, 2007, at 1:04 PM, Ivan Voras wrote: Marcel Moolenaar wrote: On Jun 9, 2007, at 9:22 AM, Ivan Voras wrote: Another thing that would be nice to have is support for fdisk and disklabel partitions inside geom_part, so it's management utility can be used for both GPT and old style partition management (instead of currently used two tools: fdisk and disklabel). I do have to make FreeBSD/ia64 boot on a rx2660, but after that I may be able to take a look at it. I know what's there and I know what's missing, so I should be able to get the partitioning stuff working Thanks! soon-ish. The bootblock requirements may take little longer, because there's where g_part is missing features. Do you mean installing boot blocks into the protective MBR via geom_part or something else? Yep. Both MBR and BSD have boot code and we need to be able to install it through the GEOM ctlreq I/F. It's not a big problem per se, but it's something that needs to be implemented. I'm thinking of a new verb (say install) that takes one or more blobs of code that the scheme knows how to handle. The boot code is installed after the partitioning scheme has been created on the disk... -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
I'm having to tackle this issue right now in DFly. With GPT having to start at sector 1 (no choice there), the compatible MBR in sector 0 presumably must have a slice (#1) which covers the entire disk. But do we have to make slice #1 bootable? Could we also create a slice #2 in the MBR that points into the GPT's first partition, mark it bootable, and thus be able to put boot1 in the GPT's first partition? Or will the BIOS fart on the overlapping MBR slices? -Matt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GPT - (last) call for action
On Jun 9, 2007, at 2:28 PM, Matthew Dillon wrote: I'm having to tackle this issue right now in DFly. With GPT having to start at sector 1 (no choice there), the compatible MBR in sector 0 presumably must have a slice (#1) which covers the entire disk. But do we have to make slice #1 bootable? Could we also create a slice #2 in the MBR that points into the GPT's first partition, mark it bootable, and thus be able to put boot1 in the GPT's first partition? Or will the BIOS fart on the overlapping MBR slices? Technically speaking, the MBR can only have a single partition of type 0xEE that covers the whole disk. This is to protect the GPT from MBR-specific tools that do not know about the GPT. This is not a bootable slice by definition. Practice is different. To support bootcamp on Intel-based Macs, the MBR will have real partitions that mirror GPT partitions or otherwise describe partitions outside the GPT controlled area. These can be bootable partitions and the protective partition (the one with type 0xEE) will not cover the whole disk anymore. The nasty part is keeping MBR and GPT partitions in sync, so it may be better to have the MBR partition fall outside the GPT controlled area. This can be done because the GPT header contains the LBA of the first and last sectors on the disk that can be assigned to a partition. You can free up space for MBR partitions after the primary GPT table by adjusting the first LBA. In the MBR partition you can put a GPT aware boot loader that uses the GPT to find the real partitions... -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
file(1) cannot detect UFS2?
Hi! I'm trying to use file(1) to detect file system type on partitions, and so far it's working for any file system I've cared to try (the usual MS and Linux list) *except* UFS2. Detecting UFS1 works, though much more verbosely than it needs to be, but UFS2 isn't detected at all. I'd like to ask someone familiar with UFS2 to take a quick peak and add the appropriate rules to the file(1) magic database, if anyone's interested. At the very least, I need someone to commit this patch: --- magic.old Fri Jun 8 17:42:01 2007 +++ magic Fri Jun 8 17:51:11 2007 @@ -4821,6 +4821,10 @@ 8320 belong 0 TIME optimization 8320 belong 1 SPACE optimization +66908 lelong 0x19540119 Unix Fast File system v2 (little-endian) + +66908 belong 0x19540119 Unix Fast File system v2 (big-endian) + # ext2/ext3 filesystems - Andreas Dilger [EMAIL PROTECTED] 0x438 leshort 0xEF53 Linux 0x44c lelong x rev %d I don't know if it's correct (the offset seems a bit high...), but it works for me :) signature.asc Description: OpenPGP digital signature
Re: file(1) cannot detect UFS2?
Ivan Voras wrote: At the very least, I need someone to commit this patch: I've attached a better, unmangled patch :) --- magic.old Fri Jun 8 17:42:01 2007 +++ magic Fri Jun 8 18:03:27 2007 @@ -4821,6 +4821,12 @@ 8320 belong 0 TIME optimization 8320 belong 1 SPACE optimization +# UFS2 / le +66908 lelong 0x19540119 Unix Fast File system v2 (little-endian) + +# UFS2 / be +66908 belong 0x19540119 Unix Fast File system v2 (big-endian) + # ext2/ext3 filesystems - Andreas Dilger [EMAIL PROTECTED] 0x438 leshort 0xEF53 Linux 0x44c lelong x rev %d signature.asc Description: OpenPGP digital signature
