Re: Unable to boot -CURRENT on Thinkpad P16s G2
On Thu, Mar 07, 2024 at 07:15:48PM +0100, Philipp Ost wrote: | On 2/28/24 21:10, Philipp Ost wrote: | [boot log stripped] | > Does anyone have any suggestions on how to proceed at this point? [...] | | Short follow-up: disabling uart0 and uart1 at the loader prompt allowed us | to boot and install FreeBSD (the -CURRENT snapshot from 2024-02-29 in case | it matters). UARTS on AMD can be a bit different. Some BIOS implementations seem to set them up to work like legacy ports others do not. On a Naples platform I helped add support for them since they were not setup in the legacy configuration. The AMD servers I'm using now have them setup in legacy mode and just work like on other systems. If I remember right those UARTS were defined in ACPI. On a laptop they probably don't have serial ports and the probe is getting stuck on something. It might be good to instrument it to see what. Thanks, Doug A.
Re: MegaCLI port is ports-only -- how would you deploy it?
On Tue, Aug 16, 2022 at 03:33:57PM -0400, Dan Mahoney wrote: | > On Aug 16, 2022, at 14:04, Doug Ambrisko wrote: | > | > On Tue, Aug 16, 2022 at 11:58:40AM -0600, Warner Losh wrote: | > |On Tue, Aug 16, 2022 at 11:40 AM Ed Maste <[1]ema...@freebsd.org> | > |wrote: | > | | > | On Mon, 15 Aug 2022 at 20:03, Doug Ambrisko | > | <[2]ambri...@ambrisko.com> wrote: | > | > | > | > I'd have to put in -current first then look at MFC later | > | on. If looks | > | > | > | > good for you then I'll put it up for review. I just don't | > | use this | > | > | > | > stuff day to day anymore. | > | I think it would be good to put this into review, perhaps separate | > | ones for the kernel and userland parts. Feel free to put me on as a | > | reviewer or subscriber. | > | | > |I can review as well. I like this plan. | > | > I'll add John as well since I think he wrote mfiutil originally. | | I haven't attached the makefile patch to the bug I opened yet. (And the | existing patch is a link, not an attach). That isn't critical since I'm the one that made it and plan to be the committer to deal with it. I grabbed ownership of the bug. I updated my personal branch with the fix so I shouldn't drop it again. I had factored out some other local changes I had in the driver. It had issue with various things that the team I used be part of would hit since that SW sent lots of concurrent I/O to the card. It was made worse on the low end system without cache. Broadcom didn't seem interested in addressing it when I used to work with them more closely. I had patches in that teams driver. | If further diagnostics are needed (I'm not going to like, try to use it | to blow away and re-create an array, sorry), I can provide SOME of that. | Just tell me how I can help. That shouldn't really be needed since the MFI commands are consistent being MegaRAID SAS controllers. The main thing that has changed is the driver. I've heard they are changing for their next controller that would require new tools and driver. In a few months I might have a machine with one to play with. | In the mean time, since the system that I'm testing this on is one of | the dayjob's console servers, and we still want to be able to run puppet | on it periodically, y'all have motivated me to get puppet to fix their | "ports" package provider, which still depends on pkg-classic binaries | being present. Not relevant to this problem, other than noting the cool | ripple effect. Thanks, Doug A.
Re: MegaCLI port is ports-only -- how would you deploy it?
On Tue, Aug 16, 2022 at 11:58:40AM -0600, Warner Losh wrote: |On Tue, Aug 16, 2022 at 11:40 AM Ed Maste <[1]ema...@freebsd.org> |wrote: | | On Mon, 15 Aug 2022 at 20:03, Doug Ambrisko | <[2]ambri...@ambrisko.com> wrote: | > | > | > I'd have to put in -current first then look at MFC later | on. If looks | > | > | > good for you then I'll put it up for review. I just don't | use this | > | > | > stuff day to day anymore. | I think it would be good to put this into review, perhaps separate | ones for the kernel and userland parts. Feel free to put me on as a | reviewer or subscriber. | |I can review as well. I like this plan. I'll add John as well since I think he wrote mfiutil originally. Thanks, Doug A.
Re: MegaCLI port is ports-only -- how would you deploy it?
On Sat, Aug 13, 2022 at 10:41:33PM -0400, Dan Mahoney wrote: | | | > On Aug 12, 2022, at 12:35, Doug Ambrisko wrote: | > | > On Fri, Aug 12, 2022 at 12:32:56PM -0400, Dan Mahoney wrote: | > | | > | | > | > On Aug 12, 2022, at 12:31, Doug Ambrisko wrote: | > | > | > | > On Fri, Aug 12, 2022 at 12:21:36PM -0400, Dan Mahoney wrote: | > | > | | > | > | > On Aug 8, 2022, at 16:45, Doug Ambrisko wrote: | > | > | > | > | > | > On Mon, Aug 08, 2022 at 04:10:10PM -0400, Dan Mahoney wrote: | > | > | > | | > | > | > | | > | > | > | > On Aug 8, 2022, at 15:57, Doug Ambrisko wrote: | > | > | > | > | > | > | > | > On Thu, Aug 04, 2022 at 05:22:29PM +0300, Ruslan Makhmatkhanov wrote: | > | > | > | > |03.08.2022, 02:07, "Dan Mahoney" : | > | > | > | > | Hey there all, | > | > | > | > | At the dayjob we have a fleet of Dell Poweredge servers that can use | > | > | > | > | either mptsas or mrsas -- if you use mptsas, you use mptutil (in | > | > | > | > | base) to check the state of the card. | > | > | > | > | If you use mrsas, you need megacli, which is only in ports, and the | > | > | > | > | port hasn't translated to pkg probably because of license | > | > | > | > | restrictions. ( _LICENSE_RESTRICTED = delete-package | > | > | > | > | delete-distfiles), but the license listed is just "megacli". | > | > | > | > | * We want to deploy a cron job to periodically check the raid status | > | > | > | > | (we're writing a wrapper, also having it check mfiutil, zpool, etc). | > | > | > | > | * We do not want to install and manage a whole ports tree on every | > | > | > | > | machine in our fleet, just to install a raid utlity. | > | > | > | > | Option A: | > | > | > | > | Make a local package somehow. | > | > | > | > | The port just downloads a static binary, there's nothing to build | > | > | > | > | here, but we want to do this the "right" way. Is there some way to | > | > | > | > | have pkg deploy a single local package for this that will, for | > | > | > | > | example, report the right package ownership, without moving every | > | > | > | > | other package to our poudriere install (we're just using base | > | > | > | > | packages, we keep poudriere around for testing in case we need to | > | > | > | > | hot-patch something). | > | > | > | > | For what it's worth, we use puppet for config management, so pushing | > | > | > | > | out the static binary is not the worst answer, but it also feels | > | > | > | > | "dirty". | > | > | > | > | Option B: | > | > | > | > | Figure out how to fix the license. I have no idea what this would | > | > | > | > | involve. | > | > | > | > | Option C: | > | > | > | > | Also, apparently MegaCLI is no longer maintained (replaced by | > | > | > | > | StorCLI), but there's no port for StorCLI, and...there are multiple | > | > | > | > | raid-card specific versions? Jeez. | > | > | > | > | Feels even more dirty. | > | > | > | > | [1]https://support.siliconmechanics.com/portal/en/kb/articles/storcl | > | > | > | > | i-for-freebsd-and-other-operating-systems | > | > | > | > | Ideas welcome? | > | > | > | > | -Dan Mahoney | > | > | > | > | > | > | > | > Although the path to get to StorCli goes through various cards the | > | > | > | > latest greatest seem to work on all earlier cards. It works on | > | > | > | > HBAs and not just RAID cards. At work I did a Linux/FreeBSD | > | > | > | > POC for FW management and found the FreeBSD version could flash the HBA | > | > | > | > and drive FW. I've moved to StorCli from MegaCli. I would suggest | > | > | > | > we drop the MegaCli port and move to StorCli. | > | > | > | > | > | > | > | > I have code to make mfiutil into mrsasutil and added the MFI ioctl | > | > | > | > handler to mrsas. I'm not sure how much value that has. I don't | > | > | > | > deal with supporting FreeBSD and RAID much anymore. If interested | > | > | > | > I could send patches. | > | > | > | | > | > | > | This feels like it should be in base, regardless. J
Re: SAS/SATA controllers: 8 port that support 8TB Drives
On Fri, Jun 17, 2022 at 05:55:50PM -0500, Larry Rosenman wrote: | On 06/17/2022 5:48 pm, Michael Gmelin wrote: | >> On 18. Jun 2022, at 00:31, Alexander Motin wrote: | >> | >> | >> | >>> On 17.06.2022 18:24, Alexander Motin wrote: | On 17.06.2022 18:16, Larry Rosenman wrote: | On 06/17/2022 5:08 pm, Alexander Motin wrote: | > On 17.06.2022 11:59, Larry Rosenman wrote: | >> I'm looking to upgrade the controllers in my TrueNAS box to | >> something that will | >> support 8TB drives because apparently my LSI 2108 controllers do | >> not support 8TB drives. | >> | >> What's the communities recommendation? | >> needs to support SFF connectors for a total of 4 SFF connectors, | >> as I have 16 slots. | > | > We at iX are still using LSI/Broadcom HBAs, just moved from long | > discontinued mps(4) to newer mpr(4). And I don't believe the | > problem | > is directly related to capacity. According to my observations it | > may | > be Seagate HDDs of/above certain (8TB) generation. We do not use | > Seagate HDDs in our products, so about that instability I only | > heard | > from forums and TrueNAS community user reports. | | This is a mfi(4) set of controllers, and a ST8Nm0045 8TB (CMR) | drive. | | Is this a bad combo? | | mfi0: 9973 (708793330s/0x0002/WARN) - PD 00(e0xfc/s3) is not | supported | (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 | (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error | (probe0:mfi0:0:0:0): Retrying command, 3 more tries remain | (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 | (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error | (probe0:mfi0:0:0:0): Retrying command, 2 more tries remain | (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 | (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error | (probe0:mfi0:0:0:0): Retrying command, 1 more tries remain | (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 | (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error | (probe0:mfi0:0:0:0): Retrying command, 0 more tries remain | (probe0:mfi0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 | (probe0:mfi0:0:0:0): CAM status: CCB request completed with an error | (probe0:mfi0:0:0:0): Error 5, Retries exhausted | | mfi0 Physical Drives: | 0 ( 932G) UNCONFIGURED GOOD >>> serial=ZA1AC912> SATA E1:S3 | >>> mfi(4) are RAIDs, not HBAs. We do not recommend RAIDs with TrueNAS | >>> due to problems with hot-plug, disk identification, etc. and so have | >>> limited experience with them. But I know some of LSI RAIDs can be | >>> reflashed into equivalent HBAs, so if they share the hardware, I can | >>> speculate that they may share some issues. | >> | >> I've just noticed "932G" instead of "8000G". It is obviously a bigger | >> problem than what we heard for HBAs. It looks like a kind of problems | >> that should not happen to HBAs, since they should not care about disk | >> capacity. | >> | > | > What does `smartctl -a ` report (especially sector sizes)? | > | > -m | > | > | >> -- | >> Alexander Motin | >> | It's not even making a mfid* node (it is a 4Kn disk) FYI, mfi never got support for 4Kn drives and is hard coded to 512. mrsas does have support so that is better to use for 4Kn and newer controllers. My day job isn't in that area anymore. I looked a bit as what it would take to support 4Kn in mfi and that required a bunch of things and structures to figure it out. Doug A.
Re: nullfs and ZFS issues
On Fri, Apr 22, 2022 at 09:04:39AM +0200, Alexander Leidinger wrote: | Quoting Doug Ambrisko (from Thu, 21 Apr 2022 | 09:38:35 -0700): | | > On Thu, Apr 21, 2022 at 03:44:02PM +0200, Alexander Leidinger wrote: | > | Quoting Mateusz Guzik (from Thu, 21 Apr 2022 | > | 14:50:42 +0200): | > | | > | > On 4/21/22, Alexander Leidinger wrote: | > | >> I tried nocache on a system with a lot of jails which use nullfs, | > | >> which showed very slow behavior in the daily periodic runs (12h runs | > | >> in the night after boot, 24h or more in subsequent nights). Now the | > | >> first nightly run after boot was finished after 4h. | > | >> | > | >> What is the benefit of not disabling the cache in nullfs? I would | > | >> expect zfs (or ufs) to cache the (meta)data anyway. | > | >> | > | > | > | > does the poor performance show up with | > | > https://people.freebsd.org/~mjg/vnlru_free_pick.diff ? | > | | > | I would like to have all the 22 jails run the periodic scripts a | > | second night in a row before trying this. | > | | > | > if the long runs are still there, can you get some profiling from it? | > | > sysctl -a before and after would be a start. | > | > | > | > My guess is that you are the vnode limit and bumping into the 1 | > second sleep. | > | | > | That would explain the behavior I see since I added the last jail | > | which seems to have crossed a threshold which triggers the slow | > | behavior. | > | | > | Current status (with the 112 nullfs mounts with nocache): | > | kern.maxvnodes: 10485760 | > | kern.numvnodes:3791064 | > | kern.freevnodes: 3613694 | > | kern.cache.stats.heldvnodes:151707 | > | kern.vnodes_created: 260288639 | > | | > | The maxvnodes value is already increased by 10 times compared to the | > | default value on this system. | > | > I've attached mount.patch that when doing mount -v should | > show the vnode usage per filesystem. Note that the problem I was | > running into was after some operations arc_prune and arc_evict would | > consume 100% of 2 cores and make ZFS really slow. If you are not | > running into that issue then nocache etc. shouldn't be needed. | | I don't run into this issue, but I have a huge perf difference when | using nocache in the nightly periodic runs. 4h instead of 12-24h (22 | jails on this system). I wouldn't do the nocache then! It would be good to see what Mateusz patch does without nocache for your env. | > On my laptop I set ARC to 1G since I don't use swap and in the past | > ARC would consume to much memory and things would die. When the | > nullfs holds a bunch of vnodes then ZFS couldn't release them. | > | > FYI, on my laptop with nocache and limited vnodes I haven't run | > into this problem. I haven't tried the patch to let ZFS free | > it's and nullfs vnodes on my laptop. I have only tried it via | | I have this patch and your mount patch installed now, without nocache | and reduced arc reclaim settings (100, 1). I will check the runtime | for the next 2 days. | | Your mount patch to show the per mount vnodes count looks useful, not | only for this particular case. Do you intend to commit it? I should since it doesn't change the size of the structure etc. I need to put it up for review. Thanks, Doug A.
Re: nullfs and ZFS issues
On Thu, Apr 21, 2022 at 03:44:02PM +0200, Alexander Leidinger wrote: | Quoting Mateusz Guzik (from Thu, 21 Apr 2022 | 14:50:42 +0200): | | > On 4/21/22, Alexander Leidinger wrote: | >> I tried nocache on a system with a lot of jails which use nullfs, | >> which showed very slow behavior in the daily periodic runs (12h runs | >> in the night after boot, 24h or more in subsequent nights). Now the | >> first nightly run after boot was finished after 4h. | >> | >> What is the benefit of not disabling the cache in nullfs? I would | >> expect zfs (or ufs) to cache the (meta)data anyway. | >> | > | > does the poor performance show up with | > https://people.freebsd.org/~mjg/vnlru_free_pick.diff ? | | I would like to have all the 22 jails run the periodic scripts a | second night in a row before trying this. | | > if the long runs are still there, can you get some profiling from it? | > sysctl -a before and after would be a start. | > | > My guess is that you are the vnode limit and bumping into the 1 second sleep. | | That would explain the behavior I see since I added the last jail | which seems to have crossed a threshold which triggers the slow | behavior. | | Current status (with the 112 nullfs mounts with nocache): | kern.maxvnodes: 10485760 | kern.numvnodes:3791064 | kern.freevnodes: 3613694 | kern.cache.stats.heldvnodes:151707 | kern.vnodes_created: 260288639 | | The maxvnodes value is already increased by 10 times compared to the | default value on this system. With the patch, you shouldn't mount with nocache! However, you might want to tune: vfs.zfs.arc.meta_prune vfs.zfs.arc.meta_adjust_restarts Since the code on restart will increment the prune amount by vfs.zfs.arc.meta_prune and submit that amount to the vnode reclaim code. So then it will end up reclaiming a lot of vnodes. The defaults of 1 * 4096 and submitting it each loop can most of the cache to be freed. With relative small values of them, then the cache didn't shrink to much. Doug A.
Re: nullfs and ZFS issues
On Thu, Apr 21, 2022 at 03:44:02PM +0200, Alexander Leidinger wrote:
| Quoting Mateusz Guzik (from Thu, 21 Apr 2022
| 14:50:42 +0200):
|
| > On 4/21/22, Alexander Leidinger wrote:
| >> I tried nocache on a system with a lot of jails which use nullfs,
| >> which showed very slow behavior in the daily periodic runs (12h runs
| >> in the night after boot, 24h or more in subsequent nights). Now the
| >> first nightly run after boot was finished after 4h.
| >>
| >> What is the benefit of not disabling the cache in nullfs? I would
| >> expect zfs (or ufs) to cache the (meta)data anyway.
| >>
| >
| > does the poor performance show up with
| > https://people.freebsd.org/~mjg/vnlru_free_pick.diff ?
|
| I would like to have all the 22 jails run the periodic scripts a
| second night in a row before trying this.
|
| > if the long runs are still there, can you get some profiling from it?
| > sysctl -a before and after would be a start.
| >
| > My guess is that you are the vnode limit and bumping into the 1 second
sleep.
|
| That would explain the behavior I see since I added the last jail
| which seems to have crossed a threshold which triggers the slow
| behavior.
|
| Current status (with the 112 nullfs mounts with nocache):
| kern.maxvnodes: 10485760
| kern.numvnodes:3791064
| kern.freevnodes: 3613694
| kern.cache.stats.heldvnodes:151707
| kern.vnodes_created: 260288639
|
| The maxvnodes value is already increased by 10 times compared to the
| default value on this system.
I've attached mount.patch that when doing mount -v should
show the vnode usage per filesystem. Note that the problem I was
running into was after some operations arc_prune and arc_evict would
consume 100% of 2 cores and make ZFS really slow. If you are not
running into that issue then nocache etc. shouldn't be needed.
On my laptop I set ARC to 1G since I don't use swap and in the past
ARC would consume to much memory and things would die. When the
nullfs holds a bunch of vnodes then ZFS couldn't release them.
FYI, on my laptop with nocache and limited vnodes I haven't run
into this problem. I haven't tried the patch to let ZFS free
it's and nullfs vnodes on my laptop. I have only tried it via
bhyve test. I use bhyve and a md drive to avoid wearing
out my SSD and it's faster to test. I have found the git, tar,
make world etc. could trigger the issue before but haven't had
any issues with nocache and capping vnodes.
Thanks,
Doug A.
diff --git a/sbin/mount/mount.c b/sbin/mount/mount.c
index 79d9d6cb0ca..00eefb3a5e0 100644
--- a/sbin/mount/mount.c
+++ b/sbin/mount/mount.c
@@ -692,6 +692,13 @@ prmount(struct statfs *sfp)
xo_emit("{D:, }{Lw:fsid}{:fsid}", fsidbuf);
free(fsidbuf);
}
+ if (sfp->f_nvnodelistsize != 0 || sfp->f_lazyvnodelistsize != 0) {
+ xo_open_container("vnodes");
+xo_emit("{D:, }{Lwc:vnodes}{Lw:count}{w:count/%ju}{Lw:lazy}{:lazy/%ju}",
+(uintmax_t)sfp->f_nvnodelistsize,
+(uintmax_t)sfp->f_lazyvnodelistsize);
+ xo_close_container("vnodes");
+ }
}
xo_emit("{D:)}\n");
}
diff --git a/sys/kern/vfs_mount.c b/sys/kern/vfs_mount.c
index a495ad86ac4..3648ef8d080 100644
--- a/sys/kern/vfs_mount.c
+++ b/sys/kern/vfs_mount.c
@@ -2625,6 +2626,8 @@ __vfs_statfs(struct mount *mp, struct statfs *sbp)
sbp->f_version = STATFS_VERSION;
sbp->f_namemax = NAME_MAX;
sbp->f_flags = mp->mnt_flag & MNT_VISFLAGMASK;
+ sbp->f_nvnodelistsize = mp->mnt_nvnodelistsize;
+ sbp->f_lazyvnodelistsize = mp->mnt_lazyvnodelistsize;
return (mp->mnt_op->vfs_statfs(mp, sbp));
}
diff --git a/sys/sys/mount.h b/sys/sys/mount.h
index 3383bfe8f43..95dd3c76ae5 100644
--- a/sys/sys/mount.h
+++ b/sys/sys/mount.h
@@ -91,7 +91,9 @@ struct statfs {
uint64_t f_asyncwrites; /* count of async writes since mount */
uint64_t f_syncreads; /* count of sync reads since mount */
uint64_t f_asyncreads; /* count of async reads since mount */
- uint64_t f_spare[10]; /* unused spare */
+ uint32_t f_nvnodelistsize; /* (i) # of vnodes */
+ uint32_t f_lazyvnodelistsize;/* (l) # of lazy vnodes */
+ uint64_t f_spare[9]; /* unused spare */
uint32_t f_namemax; /* maximum filename length */
uid_t f_owner; /* user that mounted the filesystem */
fsid_t f_fsid; /* filesystem id */
Re: nullfs and ZFS issues
On Wed, Apr 20, 2022 at 11:39:44AM +0200, Alexander Leidinger wrote: | Quoting Doug Ambrisko (from Mon, 18 Apr 2022 | 16:32:38 -0700): | | > With nullfs, nocache and settings max vnodes to a low number I can | | Where is nocache documented? I don't see it in mount_nullfs(8), | mount(8) or nullfs(5). I didn't find it but it is in: src/sys/fs/nullfs/null_vfsops.c: if (vfs_getopt(mp->mnt_optnew, "nocache", NULL, NULL) == 0 || Also some file systems disable it via MNTK_NULL_NOCACHE | I tried a nullfs mount with nocache and it doesn't show up in the | output of "mount". Yep, I saw that as well. I could tell by dropping into ddb and then do a show mount on the FS and look at the count. That is why I added the vnode count to mount -v so I could see the usage without dropping into ddb. Doug A.
Re: nullfs and ZFS issues
On Wed, Apr 20, 2022 at 11:43:10AM +0200, Mateusz Guzik wrote:
| On 4/19/22, Doug Ambrisko wrote:
| > On Tue, Apr 19, 2022 at 11:47:22AM +0200, Mateusz Guzik wrote:
| > | Try this: https://people.freebsd.org/~mjg/vnlru_free_pick.diff
| > |
| > | this is not committable but should validate whether it works fine
| >
| > As a POC it's working. I see the vnode count for the nullfs and
| > ZFS go up. The ARC cache also goes up until it exceeds the ARC max.
| > size tten the vnodes for nullfs and ZFS goes down. The ARC cache goes
| > down as well. This all repeats over and over. The systems seems
| > healthy. No excessive running of arc_prune or arc_evict.
| >
| > My only comment is that the vnode freeing seems a bit agressive.
| > Going from ~15,000 to ~200 vnode for nullfs and the same for ZFS.
| > The ARC drops from 70M to 7M (max is set at 64M) for this unit
| > test.
| >
|
| Can you check what kind of shrinking is requested by arc to begin
| with? I imagine encountering a nullfs vnode may end up recycling 2
| instead of 1, but even repeated a lot it does not explain the above.
I dug it into a bit more and think there could be a bug in:
module/zfs/arc.c
arc_evict_meta_balanced(uint64_t meta_used)
prune += zfs_arc_meta_prune;
//arc_prune_async(prune);
arc_prune_async(zfs_arc_meta_prune);
Since arc_prune_async, is queuing up a run of arc_prune_task for each
call it is actually already accumulating the zfs_arc_meta_prune
amount. It makes the count to vnlru_free_impl get really big quickly
since it is looping via restart.
1 HELLO arc_prune_task 164 ticks 2147465958 count 2048
dmesg | grep arc_prune_task | uniq -c
14 HELLO arc_prune_task 164 ticks -2147343772 count 100
50 HELLO arc_prune_task 164 ticks -2147343771 count 100
46 HELLO arc_prune_task 164 ticks -2147343770 count 100
49 HELLO arc_prune_task 164 ticks -2147343769 count 100
44 HELLO arc_prune_task 164 ticks -2147343768 count 100
116 HELLO arc_prune_task 164 ticks -2147343767 count 100
1541 HELLO arc_prune_task 164 ticks -2147343766 count 100
53 HELLO arc_prune_task 164 ticks -2147343101 count 100
100 HELLO arc_prune_task 164 ticks -2147343100 count 100
75 HELLO arc_prune_task 164 ticks -2147343099 count 100
52 HELLO arc_prune_task 164 ticks -2147343098 count 100
50 HELLO arc_prune_task 164 ticks -2147343097 count 100
51 HELLO arc_prune_task 164 ticks -2147343096 count 100
783 HELLO arc_prune_task 164 ticks -2147343095 count 100
884 HELLO arc_prune_task 164 ticks -2147343094 count 100
Note I shrunk vfs.zfs.arc.meta_prune=100 to see how that might
help. Changing it to 1, helps more! I see less agressive
swings.
I added
printf("HELLO %s %d ticks %d count
%ld\n",__FUNCTION__,__LINE__,ticks,nr_scan);
to arc_prune_task.
Adjusting both
sysctl vfs.zfs.arc.meta_adjust_restarts=1
sysctl vfs.zfs.arc.meta_prune=100
without changing arc_prune_async(prune) helps avoid excessive swings.
Thanks,
Doug A.
| > | On 4/19/22, Mateusz Guzik wrote:
| > | > On 4/19/22, Mateusz Guzik wrote:
| > | >> On 4/19/22, Doug Ambrisko wrote:
| > | >>> I've switched my laptop to use nullfs and ZFS. Previously, I used
| > | >>> localhost NFS mounts instead of nullfs when nullfs would complain
| > | >>> that it couldn't mount. Since that check has been removed, I've
| > | >>> switched to nullfs only. However, every so often my laptop would
| > | >>> get slow and the the ARC evict and prune thread would consume two
| > | >>> cores 100% until I rebooted. I had a 1G max. ARC and have increased
| > | >>> it to 2G now. Looking into this has uncovered some issues:
| > | >>> -nullfs would prevent vnlru_free_vfsops from doing
anything
| > | >>> when called from ZFS arc_prune_task
| > | >>> -nullfs would hang onto a bunch of vnodes unless mounted
with
| > | >>> nocache
| > | >>> -nullfs and nocache would break untar. This has been
fixed
| > now.
| > | >>>
| > | >>> With nullfs, nocache and settings max vnodes to a low number I can
| > | >>> keep the ARC around the max. without evict and prune consuming
| > | >>> 100% of 2 cores. This doesn't seem like the best solution but it
| > | >>> better then when the ARC starts spinning.
| > | >>>
| > | >>> Looking into this issue with bhyve and a md drive for testing I
| > create
| > | >>> a brand new zpool mounted as /test and then nullfs mount /test to
| > /mnt.
| > | >>> I loop through untaring the Linux kernel in
Re: nullfs and ZFS issues
On Tue, Apr 19, 2022 at 11:47:22AM +0200, Mateusz Guzik wrote:
| Try this: https://people.freebsd.org/~mjg/vnlru_free_pick.diff
|
| this is not committable but should validate whether it works fine
As a POC it's working. I see the vnode count for the nullfs and
ZFS go up. The ARC cache also goes up until it exceeds the ARC max.
size tten the vnodes for nullfs and ZFS goes down. The ARC cache goes
down as well. This all repeats over and over. The systems seems
healthy. No excessive running of arc_prune or arc_evict.
My only comment is that the vnode freeing seems a bit agressive.
Going from ~15,000 to ~200 vnode for nullfs and the same for ZFS.
The ARC drops from 70M to 7M (max is set at 64M) for this unit
test.
Thanks,
Doug A.
| On 4/19/22, Mateusz Guzik wrote:
| > On 4/19/22, Mateusz Guzik wrote:
| >> On 4/19/22, Doug Ambrisko wrote:
| >>> I've switched my laptop to use nullfs and ZFS. Previously, I used
| >>> localhost NFS mounts instead of nullfs when nullfs would complain
| >>> that it couldn't mount. Since that check has been removed, I've
| >>> switched to nullfs only. However, every so often my laptop would
| >>> get slow and the the ARC evict and prune thread would consume two
| >>> cores 100% until I rebooted. I had a 1G max. ARC and have increased
| >>> it to 2G now. Looking into this has uncovered some issues:
| >>> -nullfs would prevent vnlru_free_vfsops from doing anything
| >>> when called from ZFS arc_prune_task
| >>> -nullfs would hang onto a bunch of vnodes unless mounted with
| >>> nocache
| >>> -nullfs and nocache would break untar. This has been fixed now.
| >>>
| >>> With nullfs, nocache and settings max vnodes to a low number I can
| >>> keep the ARC around the max. without evict and prune consuming
| >>> 100% of 2 cores. This doesn't seem like the best solution but it
| >>> better then when the ARC starts spinning.
| >>>
| >>> Looking into this issue with bhyve and a md drive for testing I create
| >>> a brand new zpool mounted as /test and then nullfs mount /test to /mnt.
| >>> I loop through untaring the Linux kernel into the nullfs mount, rm -rf
| >>> it
| >>> and repeat. I set the ARC to the smallest value I can. Untarring the
| >>> Linux kernel was enough to get the ARC evict and prune to spin since
| >>> they couldn't evict/prune anything.
| >>>
| >>> Looking at vnlru_free_vfsops called from ZFS arc_prune_task I see it
| >>> static int
| >>> vnlru_free_impl(int count, struct vfsops *mnt_op, struct vnode *mvp)
| >>> {
| >>> ...
| >>>
| >>> for (;;) {
| >>> ...
| >>> vp = TAILQ_NEXT(vp, v_vnodelist);
| >>> ...
| >>>
| >>> /*
| >>> * Don't recycle if our vnode is from different type
| >>> * of mount point. Note that mp is type-safe, the
| >>> * check does not reach unmapped address even if
| >>> * vnode is reclaimed.
| >>> */
| >>> if (mnt_op != NULL && (mp = vp->v_mount) != NULL &&
| >>> mp->mnt_op != mnt_op) {
| >>> continue;
| >>> }
| >>> ...
| >>>
| >>> The vp ends up being the nulfs mount and then hits the continue
| >>> even though the passed in mvp is on ZFS. If I do a hack to
| >>> comment out the continue then I see the ARC, nullfs vnodes and
| >>> ZFS vnodes grow. When the ARC calls arc_prune_task that calls
| >>> vnlru_free_vfsops and now the vnodes go down for nullfs and ZFS.
| >>> The ARC cache usage also goes down. Then they increase again until
| >>> the ARC gets full and then they go down again. So with this hack
| >>> I don't need nocache passed to nullfs and I don't need to limit
| >>> the max vnodes. Doing multiple untars in parallel over and over
| >>> doesn't seem to cause any issues for this test. I'm not saying
| >>> commenting out continue is the fix but a simple POC test.
| >>>
| >>
| >> I don't see an easy way to say "this is a nullfs vnode holding onto a
| >> zfs vnode". Perhaps the routine can be extrended with issuing a nullfs
| >> callback, if the module is loaded.
| >>
| >> In the meantime I think a good enough(tm) fix would be to check that
| >> nothing was freed and fallback to good old regular
nullfs and ZFS issues
I've switched my laptop to use nullfs and ZFS. Previously, I used
localhost NFS mounts instead of nullfs when nullfs would complain
that it couldn't mount. Since that check has been removed, I've
switched to nullfs only. However, every so often my laptop would
get slow and the the ARC evict and prune thread would consume two
cores 100% until I rebooted. I had a 1G max. ARC and have increased
it to 2G now. Looking into this has uncovered some issues:
- nullfs would prevent vnlru_free_vfsops from doing anything
when called from ZFS arc_prune_task
- nullfs would hang onto a bunch of vnodes unless mounted with
nocache
- nullfs and nocache would break untar. This has been fixed now.
With nullfs, nocache and settings max vnodes to a low number I can
keep the ARC around the max. without evict and prune consuming
100% of 2 cores. This doesn't seem like the best solution but it
better then when the ARC starts spinning.
Looking into this issue with bhyve and a md drive for testing I create
a brand new zpool mounted as /test and then nullfs mount /test to /mnt.
I loop through untaring the Linux kernel into the nullfs mount, rm -rf it
and repeat. I set the ARC to the smallest value I can. Untarring the
Linux kernel was enough to get the ARC evict and prune to spin since
they couldn't evict/prune anything.
Looking at vnlru_free_vfsops called from ZFS arc_prune_task I see it
static int
vnlru_free_impl(int count, struct vfsops *mnt_op, struct vnode *mvp)
{
...
for (;;) {
...
vp = TAILQ_NEXT(vp, v_vnodelist);
...
/*
* Don't recycle if our vnode is from different type
* of mount point. Note that mp is type-safe, the
* check does not reach unmapped address even if
* vnode is reclaimed.
*/
if (mnt_op != NULL && (mp = vp->v_mount) != NULL &&
mp->mnt_op != mnt_op) {
continue;
}
...
The vp ends up being the nulfs mount and then hits the continue
even though the passed in mvp is on ZFS. If I do a hack to
comment out the continue then I see the ARC, nullfs vnodes and
ZFS vnodes grow. When the ARC calls arc_prune_task that calls
vnlru_free_vfsops and now the vnodes go down for nullfs and ZFS.
The ARC cache usage also goes down. Then they increase again until
the ARC gets full and then they go down again. So with this hack
I don't need nocache passed to nullfs and I don't need to limit
the max vnodes. Doing multiple untars in parallel over and over
doesn't seem to cause any issues for this test. I'm not saying
commenting out continue is the fix but a simple POC test.
It appears that when ZFS is asking for cached vnodes to be
free'd nullfs also needs to free some up as well so that
they are free'd on the VFS level. It seems that vnlru_free_impl
should allow some of the related nullfs vnodes to be free'd so
the ZFS ones can be free'd and reduce the size of the ARC.
BTW, I also hacked the kernel and mount to show the vnodes used
per mount ie. mount -v:
test on /test (zfs, NFS exported, local, nfsv4acls, fsid 2b23b2a1de21ed66,
vnodes: count 13846 lazy 0)
/test on /mnt (nullfs, NFS exported, local, nfsv4acls, fsid 11ff00292900,
vnodes: count 13846 lazy 0)
Now I can easily see how the vnodes are used without going into ddb.
On my laptop I have various vnet jails and nullfs mount my homedir into
them so pretty much everything goes through nullfs to ZFS. I'm limping
along with the nullfs nocache and small number of vnodes but it would be
nice to not need that.
Thanks,
Doug A.
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Wed, Aug 08, 2018 at 01:42:07AM +0300, Konstantin Belousov wrote:
| On Tue, Aug 07, 2018 at 02:49:10PM -0700, Doug Ambrisko wrote:
| > On Tue, Aug 07, 2018 at 08:29:49PM +0300, Konstantin Belousov wrote:
| > | On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote:
| > | > On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote:
| > | > > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote:
| > | > >>
| > | > >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov
wrote:
| > | > >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote:
| > | > >> >>
| > | > >> >> He now gets a little further, but ends up with the same panic due
to
| > | > >> >> efirtc_probe trying to get time to verify the rtc's actually
| > | > >> >> implemented. What kind of approach must we take to ensure curcpu
is
| > | > >> >> synced?
| > | > >> >
| > | > >> > It does not panic for me, when I load efirt.ko from the loader
prompt.
| > | > >> > Anyway, try this
| > | > >>
| > | > >> Right, I also don't get a panic on any of my machines from this.
| > | > >> Hopefully he'll have a chance to try this soon.
| > | > >
| > | > > This change has no impact: it still panics in the same way as without
the patch.
| > | > >
| > | >
| > | > That seems indicative of a bigger problem, since we use proc0
| > | > throughout all these bits so we should still be dealing with the same
| > | > pmap that got passed to pmap_pinit0 when we grab
| > | > curthread->td_proc->p_vmspace->vm_pmap.
| > |
| > | Can you confirm that you get the early efi_enter() call from rtc code,
| > | when you preload the module or compile it into the kernel ?
| >
| > When I ran into this, I did this change:
| >
| > Index: dev/efidev/efirt.c
| > ===
| > --- dev/efidev/efirt.c (revision 337264)
| > +++ dev/efidev/efirt.c (working copy)
| > @@ -257,7 +257,8 @@
| > if (efi_runtime == NULL)
| > return (ENXIO);
| > td = curthread;
| > - curpmap = &td->td_proc->p_vmspace->vm_pmap;
| > +// curpmap = &td->td_proc->p_vmspace->vm_pmap;
| > + curpmap = PCPU_GET(curpmap);
| > PMAP_LOCK(curpmap);
| > mtx_lock(&efi_lock);
| > fpu_kern_enter(td, NULL, FPU_KERN_NOCTX);
| > @@ -272,7 +273,8 @@
| >
| > efi_arch_leave();
| >
| > - curpmap = &curproc->p_vmspace->vm_pmap;
| > +// curpmap = &curproc->p_vmspace->vm_pmap;
| > + curpmap = PCPU_GET(curpmap);
| > td = curthread;
| > fpu_kern_leave(td, NULL);
| > mtx_unlock(&efi_lock);
| >
| > Don't know if it is right. Some previous code used both
| > curpmap = PCPU_GET(curpmap);
| > and
| > curpmap = &td->td_proc->p_vmspace->vm_pmap;
| > recently it was changes to only use
| > curpmap = &td->td_proc->p_vmspace->vm_pmap;
| >
| > Things seem to work after that. I was able to repro. it with
| > qemu-system-x86_64 in UEFI mode. I think it also failed in
| > bhyve UEFI mode.
|
| The pcpu curpmap and curproc vmspace pmap should be synced. Esp. since
| there is code relying on this early. I do not want to paper it over.
|
| In fact, try this please. Ignore my previous change.
|
| diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
| index 572b2197453..4bce36cc0e5 100644
| --- a/sys/amd64/amd64/pmap.c
| +++ b/sys/amd64/amd64/pmap.c
| @@ -7536,7 +7536,8 @@ pmap_activate_sw(struct thread *td)
| PCPU_SET(kcr3, pmap->pm_cr3);
| PCPU_SET(ucr3, pmap->pm_ucr3);
| }
| - }
| + } else
| + PCPU_SET(curpmap, pmap);
| if (pmap->pm_ucr3 != PMAP_NO_CR3) {
| rsp0 = ((vm_offset_t)PCPU_PTR(pti_stack) +
| PC_PTI_STACK_SZ * sizeof(uint64_t)) & ~0xful;
That works for qemu and bhyve booting in UEFI PXE mode. I backed
out my other change and synced to head.
Thanks,
Doug A.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Tue, Aug 07, 2018 at 08:29:49PM +0300, Konstantin Belousov wrote: | On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote: | > On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote: | > > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote: | > >> | > >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov wrote: | > >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote: | > >> >> | > >> >> He now gets a little further, but ends up with the same panic due to | > >> >> efirtc_probe trying to get time to verify the rtc's actually | > >> >> implemented. What kind of approach must we take to ensure curcpu is | > >> >> synced? | > >> > | > >> > It does not panic for me, when I load efirt.ko from the loader prompt. | > >> > Anyway, try this | > >> | > >> Right, I also don't get a panic on any of my machines from this. | > >> Hopefully he'll have a chance to try this soon. | > > | > > This change has no impact: it still panics in the same way as without the patch. | > > | > | > That seems indicative of a bigger problem, since we use proc0 | > throughout all these bits so we should still be dealing with the same | > pmap that got passed to pmap_pinit0 when we grab | > curthread->td_proc->p_vmspace->vm_pmap. | | Can you confirm that you get the early efi_enter() call from rtc code, | when you preload the module or compile it into the kernel ? When I ran into this, I did this change: Index: dev/efidev/efirt.c === --- dev/efidev/efirt.c (revision 337264) +++ dev/efidev/efirt.c (working copy) @@ -257,7 +257,8 @@ if (efi_runtime == NULL) return (ENXIO); td = curthread; - curpmap = &td->td_proc->p_vmspace->vm_pmap; +// curpmap = &td->td_proc->p_vmspace->vm_pmap; + curpmap = PCPU_GET(curpmap); PMAP_LOCK(curpmap); mtx_lock(&efi_lock); fpu_kern_enter(td, NULL, FPU_KERN_NOCTX); @@ -272,7 +273,8 @@ efi_arch_leave(); - curpmap = &curproc->p_vmspace->vm_pmap; +// curpmap = &curproc->p_vmspace->vm_pmap; + curpmap = PCPU_GET(curpmap); td = curthread; fpu_kern_leave(td, NULL); mtx_unlock(&efi_lock); Don't know if it is right. Some previous code used both curpmap = PCPU_GET(curpmap); and curpmap = &td->td_proc->p_vmspace->vm_pmap; recently it was changes to only use curpmap = &td->td_proc->p_vmspace->vm_pmap; Things seem to work after that. I was able to repro. it with qemu-system-x86_64 in UEFI mode. I think it also failed in bhyve UEFI mode. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: old bug: mount_nfs path/name is limited to 88 chars
On Tue, Jan 20, 2015 at 12:45:32PM +0100, Willem Jan Withagen wrote: | On 2015-01-20 2:05, Xin Li wrote: | >>Doing it in 11 makes sense since there is a compat layer for 10 | >>now? if I knew all of the steps I would happily do them as annoys | >>me from time to time as well with the path length issue. | > | >Compat layer may break applications in other funny ways and we | >probably have to return e.g. ENAMETOOLONG for legacy applications if | >the names are too long to fit into the buffer, but I don't see any | >easy solution either: I wish we have bumped it in 2003 when the struct | >receives its first big revamp by bumping all statistic fields to 64-bit. | | On 2015-01-20 1:23, Allan Jude wrote:> On 2015-01-19 16:20, Garrett > | > Especially with ZFS, I find I have a lot more mounts now, under longer | > and longer path names, and then I have | > .zfs/snapshots/snapshotnamehere/path/to/file | > | > etc. | > | > Definitely a +1 for "this is something we need for 11" | | +1 | | Well to be honest: Things are already broken for me ATM. | I do have paths that are too long, and tools trip over it. | | Things like building the locate database just don't have everything. | Which is a pain, especially for finding things fast in backups of ZFS, | where the path is even more convoluted that what Allan suggests | | So whether being bitten by the cat of the dog: it still hurts. | | Perhaps it is an intermediate solution to add new settings which are | going to be used for userspace programs, like USER_MNAMELEN and | USER_PATH_MAX. It will certainly give ENAMETOOLONG back when it involves | systemcalls. But then a lot of the other tool stuff would just function. I have a patch at: http://www.ambrisko.com/doug/mount/latest.patch for -current (Nov). It should work with most file systems, that is I tried to cover them all. I haven't tested with ZFS but it should work. I left some debug "HELLO's" in there just to make sure mounting looked right. They can be safely deleted. If someone wants to test it and report issues (with a simple test case) I can fix it and add it to my test script. This code won't be going into FreeBSD now since the 64 bit inode will negate the need for it since the size will be a lot larger. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SMBus controller
On Sat, Jun 14, 2014 at 04:48:30PM -0700, Sean Bruno wrote: | On Sat, 2014-06-14 at 17:25 -0600, Warner Losh wrote: | > On Jun 14, 2014, at 4:43 PM, Sean Bruno wrote: | > | > > On Sat, 2014-06-14 at 12:08 -0700, Sean Bruno wrote: | > >> I note that my TLenovo 61 has one of these: | > >> | > >> ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x20a917aa chip=0x283e8086 | > >> rev=0x03 hdr=0x00 | > >>vendor = 'Intel Corporation' | > >>device = '82801H (ICH8 Family) SMBus Controller' | > >>class = serial bus | > >>subclass = SMBus | > >> | > >> | > > | > > So, there's something broken in the initialization of the driver and the | > > driver dependencies here. | > > | > > If I load "smb.ko" by itself, no other modules are loaded (ichsmb, | > > smbus). Should it? | > | > I don't think so. If I kldload pci, would you expect most of the | > drivers in the system to be loaded? | | Heck if I know. :-) | | I would suspect that of the three, ichsmb, smbus or smb, one of these | should cause the other two to be loaded. This is not the case. ... catching up on email I wouldn't since these act at various levels. ichsmb is the HW interface of which there are different HW interfaces. Then you want the generic stack on that. You might want a user land interface. There are kernel consumers like IPMI SSIF and other things that have been done at companies. So wouldn't expect loading smb to load a i2c printer port bit banger driver of which is wrong for that HW. One word of warning is that it appears ACPI has methods to talk to the i2c bus. I've been concerned that there could be fights between ACPI accessing stuff and FreeBSD native drivers. On the HW that I have used this stuff, it wasn't a problem. I'd be a little concerned on a laptop since a lot of things can be tied to a i2c bus that ACPI wants to talk to. On a server/desktop I haven't run into that problem. I've noticed there seem to be i2c buses for displays which seems to be separate. I've made i2c interface to machines via PCI slots or soldered wires onto DIMMs. Some motherboard have i2c headers. It's easily hackable to add widgets to HW that way since there are so many i2c widgets out there. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipmi patch for review
On Thu, Sep 19, 2013 at 03:04:46PM -0400, John Baldwin wrote: | On Tuesday, September 17, 2013 6:21:10 am Gleb Smirnoff wrote: | > Hi! | > | > When system is writing a kernel core dump, it issues watchdog | > pat wdog_kern_pat(WD_LASTVAL). If ipmi is in action, it registers | > ipmi_wd_event() as event for watchdog. Thus ipmi_wd_event() is | > called in dumping context. | > | > The problem is that ipmi_wd_event() calls into ipmi_set_watchdog(), | > that calls into ipmi_alloc_request(), which uses M_WAITOK and | > thus sleeps. This is a smaller problem, since can be converted to | > M_NOWAIT. But ipmi_set_watchdog() then calls into | > ipmi_submit_driver_request(), which calls msleep() any time. | > | > The attached patch allows me to successfully write cores in | > presence of IPMI. | | Of course, the watchdog might go off during your dump. :) | | The real fix is more complicated, which is that we should not use | a worker thread for at least SMIC and KCS. I haven't looked at this patch but I have local code that switches KCS into polling direct mode when the kernel goes into panic mode. I use this to write Linux compatible back traces into the system event logs. This could allow the watchdogd to continue to work. This should be easily extended to SMIC mode. SMBUS would be harder but at a prior company I made the SMBIO driver work in polled mode. If someone wants to look at this I can post the changes for KCS and the kernel backtrace to the system event log. We find this useful when looking at customer machines. IPMI gets upset if things get intermixed/interrupted so there needs to be serialization and cancellation if being interrupted. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: newcons comming
On Mon, Nov 04, 2013 at 10:30:39AM -0500, Ed Maste wrote: | On 4 November 2013 02:16, Kevin Oberman wrote: | > Excellent news. I'm really looking forward to newcons. Guess it's time to | > move my T520 to 10-Stable (or Beta) | | I'm running a Newcons kernel on my Thinkpad X220 now and it's working | well, with a few minor quirks. This is with the X-related packages | rebuilt with WITH_NEW_XORG= and WITH_KMS= in /etc/make.conf. | | > Are you booting directly to X or using startx from the console? In either | > case, I think that i915kms should auto-load at the start of X, so you | > should not need to pre-load it. | | I log in and running startx. i915kms does auto-load. | | > Does newcons require VESA? If not, you should be able to remove it from | > your kernel to get suspend/resume working from X. | | It does not use VESA - it's removed from GENERIC on the newcons | branch. Suspend and resume generally works on my X220 now, from X or | console. There are some outstanding issues, for example the X display | sometimes ends up corrupted after resume; stopping and restarting X | fixes that. Adding vidcontrol -s 1 < /dev/ttyv0 to /etc/rc.suspend and vidcontrol -s 9 < /dev/ttyv0 to /etc/rc.resume fixed that for me. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: newcons comming
On Sun, Nov 03, 2013 at 11:16:53PM -0800, Kevin Oberman wrote: |On Thu, Oct 31, 2013 at 2:01 PM, Doug Ambrisko |wrote: | | On Fri, Oct 25, 2013 at 03:18:47PM +0300, Aleksandr Rybalko wrote: | | Hello fellow hackers! | | | | I finally reach the point when I can work with newcons instead of | | syscons on my laptop. Yes, I know it still buggy and have a lot of | | style(9) problems. But we really have to get it into HEAD and 10.0 to | | enable shiny new Xorg features, drivers, etc. | | I built the kernel from: | A A A A base/user/ed/newcons/ | and installed it on my new ThinkPad T530 with Intel graphics chip. | In general it works better since now syspend and resume works with | and without X. A However, as with my prior ThinkPads I need to switch | out of X to suspend and resume. A So I have vidcontrol -s 1 in my | /etc/rc.suspend and vidcontrol -s 9 in /etc/rc.resume. A If I don't | the display ends up corrupted but somewhat working. | | I had to kldload i915kms in /etc/rc.local since having it there at | boot via /boot/loader.conf resulted in the system not booting. A I need | i915kms for X so I don't need to use vesa mode. | | The FreeBSD logo on boot is interesting but I'd prefer seeing | FreeBSD boot messages to see what is happening. A I'm not sure if | there is a flag to disable that since I have played with it much. | | However, on a whole it is much improved since with i915kms and | newcons when in X via vesa I couldn't switch to a non-X display | since it was blank. | |Excellent news. I'm really looking forward to newcons. Guess it's time to |move my T520 to 10-Stable (or Beta) |. |Since I'm not running 10, I may simply be clueless. If so, please ignore |the rest of this. Newcons isn't in 10 yet but in its own branch. |Are you booting directly to X or using startx from the console? In either |case, I think that i915kms should auto-load at the start of X, so you |should not need to pre-load it. I use XDM to start X. Auto load might not quite work for me since I run X in a vimage jail. I find it easier to keep my base system a minimal install to start up a bounch of vimage jails. I have two "mains" that are FreeBSD -current that I leap frog and then have a couple of -stable release (ie. 9.0 and 9.2 now) that I use to build ports. I nulls mount the /var/db/pkg, /usr/local and /usr/ports of that release between those so my ports tend to be fixed in time. I have some patches to jail to allow any sysctls and to set what the OS reports for uname etc. Then pkg_add, ports builds thinks it is running on that version of FreeBSD (ie. 9.2 release). This makes it easier for me to run -current and let me add things without issue later on trying to add something new. I do have to build modules outside so it is in sync. with my base OS. |Does newcons require VESA? If not, you should be able to remove it from |your kernel to get suspend/resume working from X. As soon as I went to newcons the suspend and resume started to work. I don't have vesa kldload or static in the kernel. I auto switch out of X on suspend and switch back to X on resume to ensure that on resume the X display isn't messed up (lines shifted etc.). If I don't do this then the X gets messed up. I can see stuff working on the LCD it's just messed up. Brightness seems messed up, I patched acpi_video to also set the 2nd LCD (SB.PCI0.PEG.VID.LCD0._BCM) so that works since the keys don't work. However when X comes back from resume or dpms then it is full bridgtness. So I need to figure that out. I also run into the "N" compatibility issue with the iwn 6205 that Sean did so I #ifdef'ed that out like he did. Now the 6205 works fine. My other laptop with a 5300 didn't have this issue. My only real problem right now is that this new laptop came with a defective key so I'm waiting to get that replaced and then I'll switch to it. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: newcons comming
On Fri, Oct 25, 2013 at 03:18:47PM +0300, Aleksandr Rybalko wrote: | Hello fellow hackers! | | I finally reach the point when I can work with newcons instead of | syscons on my laptop. Yes, I know it still buggy and have a lot of | style(9) problems. But we really have to get it into HEAD and 10.0 to | enable shiny new Xorg features, drivers, etc. I built the kernel from: base/user/ed/newcons/ and installed it on my new ThinkPad T530 with Intel graphics chip. In general it works better since now syspend and resume works with and without X. However, as with my prior ThinkPads I need to switch out of X to suspend and resume. So I have vidcontrol -s 1 in my /etc/rc.suspend and vidcontrol -s 9 in /etc/rc.resume. If I don't the display ends up corrupted but somewhat working. I had to kldload i915kms in /etc/rc.local since having it there at boot via /boot/loader.conf resulted in the system not booting. I need i915kms for X so I don't need to use vesa mode. The FreeBSD logo on boot is interesting but I'd prefer seeing FreeBSD boot messages to see what is happening. I'm not sure if there is a flag to disable that since I have played with it much. However, on a whole it is much improved since with i915kms and newcons when in X via vesa I couldn't switch to a non-X display since it was blank. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem with r255775 include/mk-osreldate.sh
On Wed, Sep 25, 2013 at 12:16:47PM -0600, Ian Lepore wrote:
| On Wed, 2013-09-25 at 10:52 -0700, Doug Ambrisko wrote:
| > I don't know if others have run into this but I hit a problem with
| > include/mk-osreldate.sh. It does a set -e to exit on commands failing
| > and sources in sys/conf/newvers.sh to get various things set.
| > In newvers.sh it does a bunch of
| >
| > if [ $? -eq 0 ]; then
| > to decide what to do when it passes or fails. Unfortunately, when
| > it fails due to the "set -e" it just exits and doesn't do the
| > else clause. For me I check out a svn tree then build in a chroot.
| > In the chroot svn was failing then not creating a osreldate.h
| > resulting in the build dying. This happened on two different machines
| > of which I use this method.
| >
| > Removing the set -e in mk-osreldate.sh "fixed" my problem. It should
| > probably be reworked to not depend on set -e and print errors when things
| > fail. I guess newvers.sh could be reworked to do
| > if ; then
| > which should pass set -e.
| >
| > What do folks think? It would be good to get this fixed before MFC
| > and before 10 is released.
|
| For such a "simple" little change, this sure has been problematic.
| There are as many ways for it to fail as there are ways to arrange
| checkout-and-build workflows, apparently.
|
| I've been mostly inclined to stay away from any big changes in
| newvers.sh for fear of breaking it when it's used in some way I'm not
| familiar with (such as building a release). Sticking with that theory,
| I'd be inclined to leave it alone again, and not push the 'set -e'
| problem into its world, and instead do something like the attached.
Yes, I'd be nervous to touch newvers.sh as well.
| My thinking is that newvers.sh does a variety of things, only some of
| which are germane to the needs of mk-osreldate.h, so have mk-osreldate
| check for just what it needs, and let newvers.sh take care of its
| internal errors however it likes.
Index: include/mk-osreldate.sh
===
--- include/mk-osreldate.sh (revision 255775)
+++ include/mk-osreldate.sh (working copy)
@@ -25,8 +25,6 @@
#
# $FreeBSD$
-set -e
-
CURDIR=$(pwd)
ECHO=${ECHO:=echo}
@@ -37,6 +35,12 @@ ${ECHO} creating osreldate.h from newvers.sh
export PARAMFILE="${PARAM_H:=$CURDIR/../sys/sys/param.h}"
. "${NEWVERS_SH:=$CURDIR/../sys/conf/newvers.sh}"
+
+if [ -z "${COPYRIGHT}" -o -z "${RELDATE}" ] ; then
+${ECHO} "newvers.sh did not generate required information"
+exit 1
+fi
+
cat > $tmpfile <http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Problem with r255775 include/mk-osreldate.sh
I don't know if others have run into this but I hit a problem with include/mk-osreldate.sh. It does a set -e to exit on commands failing and sources in sys/conf/newvers.sh to get various things set. In newvers.sh it does a bunch of if [ $? -eq 0 ]; then to decide what to do when it passes or fails. Unfortunately, when it fails due to the "set -e" it just exits and doesn't do the else clause. For me I check out a svn tree then build in a chroot. In the chroot svn was failing then not creating a osreldate.h resulting in the build dying. This happened on two different machines of which I use this method. Removing the set -e in mk-osreldate.sh "fixed" my problem. It should probably be reworked to not depend on set -e and print errors when things fail. I guess newvers.sh could be reworked to do if ; then which should pass set -e. What do folks think? It would be good to get this fixed before MFC and before 10 is released. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Kernel output interleaved on boot
On Sun, Apr 07, 2013 at 09:52:37PM -0700, Jeremy Chadwick wrote: | I have discussed this problem for years now -- over 5 years, to be | exact. As if I haven't sounded like a broken record before, I surely do | now. Start here, under section "Kernel", item "Scrambled or garbled | kernel output": | | https://wiki.freebsd.org/BugBusting/Commonly_reported_issues | | The problem has not gone away. It has not been solved. It has not been | worked around. PRINTF_BUFR_SIZE does not solve the problem, and rarely | helps relieve it. | | I have discussed this issue more recently (2010) with John Baldwin as | well: | | http://lists.freebsd.org/pipermail/freebsd-questions/2010-March/214412.html | http://lists.freebsd.org/pipermail/freebsd-questions/2010-March/214423.html | | And in December 2011 too -- particularly an important read if you think | increasing the number is a wise idea: | | http://lists.freebsd.org/pipermail/freebsd-stable/2011-December/065158.html | | Bottom line: there is no solution other than to switch OSes. I have tweaked some kernel message generaters to be more line based. We had issues with CAM attached devices print out parts separately and then get intermixed a lot. So I modified them to print them as one line. Then they didn't seem to get intermixed. This doesn't solve the overall problem, but if messages are done more this way then it helps. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: serial console not accepting input?
On Thu, Jan 24, 2013 at 01:23:50PM +, Eggert, Lars wrote:
| Hi,
|
| On Jan 23, 2013, at 17:04, Dimitry Andric wrote:
| > CTS/RTS hardware flow control, maybe? E.g. add ":hw" to the default
| > settings in /etc/gettytab, or make a specific entry with an added ":hw"
| > setting.
|
| nope, I don't even get a login prompt if I do that.
|
| > If it is a physical serial console, you could also simply have a bad
| > cable. Try swapping it with working system. :)
|
| Spent the last few hours fiddling with the cabling and the various BIOS
| serial redirection options (it's a Dell 2950). My best guess is that
| the serial port on the box is physically broken.
Try to do a {Ctrl}D to see if works. We've seen that the TX on reset
hangs but input works fine. I'm not sure if we ran into this with
uart(4) but had a problem with sio(4).
Doug A.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot2/loader: serial port handling
On Fri, Oct 12, 2012 at 05:13:47PM -0700, Garrett Cooper wrote: | On Fri, Oct 12, 2012 at 5:09 PM, Xin Li wrote: | > -BEGIN PGP SIGNED MESSAGE- | > Hash: SHA256 | | ... | | > Ah I wish I am not this far behind my email backlog. Yes I think | > these (241300 and 241301) will solve the problem. | | Yeah -- forgot about the other one. There's another enhancement | that would make this even better (apart from maybe having multiple | primary consoles): setting the primary console if present and having | fallbacks in the event that the original primary wasn't set or | configurable; it was a thing that was present in another project I | worked on with sio that was pretty slick (and I think that there would | be some parties who wouldn't mind if the same was done with uart(4)). This concept was objected to when I checked it into sio(4) so I had to back it out. Some liked it. I have ported it to uart(4) since we need that functionality when we moved to a newer FreeBSD. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: projects/mfi_head to -current next week
Alex Keda writes: | On 16.03.2012 19:39, Doug Ambrisko wrote: | > Hi folks, | > | > I'd like to start merging mfi(4) from projects/head_mfi into -current | > next week. The mfi(4) driver is stable and I don't know of any issues | > with it now. I fixed a few issues that I knew of this past week. Several | > people have contributed to this. LSI did the base HW support. This | > update supports all current mfi based cards. It supports JBOD via creating | > /sys/mfisyspd* entries for each disk. When a disk is pulled from the | > controller the node goes away and when a disk is inserted it creates an | > entry. Using a fairly new MegaCli, it can also control how JBOD support | > works. We may need to update our port. This JBOD support is not the same | > as CAM pass through that some have hacked to make disks appear as da*. | > | > Several people are using this driver now so I feel it is stable enough | > to hit the tree. More eyes and people using this will make it better. | > This new HW is showing up more and more in new systems so it will make | > it easier for people to use FreeBSD on these machines and have it just | > work. | > | > Thanks to LSI for the initial HW support and all of the people that have | > been testing and getting it in shape to commit. | | Good news! | How about new hardware? Although delayed due to finding some header issues when I tested creating RAID's this is now in -current ... and yes it supports all known MFI type cards. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
projects/mfi_head to -current next week
Hi folks, I'd like to start merging mfi(4) from projects/head_mfi into -current next week. The mfi(4) driver is stable and I don't know of any issues with it now. I fixed a few issues that I knew of this past week. Several people have contributed to this. LSI did the base HW support. This update supports all current mfi based cards. It supports JBOD via creating /sys/mfisyspd* entries for each disk. When a disk is pulled from the controller the node goes away and when a disk is inserted it creates an entry. Using a fairly new MegaCli, it can also control how JBOD support works. We may need to update our port. This JBOD support is not the same as CAM pass through that some have hacked to make disks appear as da*. Several people are using this driver now so I feel it is stable enough to hit the tree. More eyes and people using this will make it better. This new HW is showing up more and more in new systems so it will make it easier for people to use FreeBSD on these machines and have it just work. Thanks to LSI for the initial HW support and all of the people that have been testing and getting it in shape to commit. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: knlist_empty locking fix
John Baldwin writes:
| On Friday, January 27, 2012 12:52:18 pm Kostik Belousov wrote:
| > On Fri, Jan 27, 2012 at 09:42:58AM -0800, Doug Ambrisko wrote:
| > > Andrew Boyer writes:
| > > | On Jan 27, 2012, at 12:15 PM, Doug Ambrisko wrote:
| > > |
| > > | > John Baldwin writes:
| > > | > | Agreed, I think the missing locking should just be added to the aio
| code.
| > > | >
| > > | > Okay so then just:
| > > | >
| > > | > Index: vfs_aio.c
| > > | > ===
| > > | > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v
| > > | > retrieving revision 1.243.2.3.4.1
| > > | > diff -u -p -r1.243.2.3.4.1 vfs_aio.c
| > > | > --- vfs_aio.c 21 Dec 2010 17:09:25 - 1.243.2.3.4.1
| > > | > +++ vfs_aio.c 27 Jan 2012 17:07:11 -
| > > | > @@ -2509,9 +2509,12 @@ static void
| > > | > filt_aiodetach(struct knote *kn)
| > > | > {
| > > | > struct aiocblist *aiocbe = kn->kn_ptr.p_aio;
| > > | > + struct knlist *knl = &aiocbe->klist;
| > > | >
| > > | > - if (!knlist_empty(&aiocbe->klist))
| > > | > - knlist_remove(&aiocbe->klist, kn, 0);
| > > | > + knl->kl_lock(knl->kl_lockarg);
| > > | > + if (!knlist_empty(knl))
| > > | > + knlist_remove(knl, kn, 1);
| > > | > + knl->kl_unlock(knl->kl_lockarg);
| > > | > }
| > > | >
| > > | > /* kqueue filter function */
| > > | >
| > > | > I was trying to be consistant with knlist_remove but this is a much
| > > | > smaller change that can be merge to older branches.
| > > |
| > > | Does filt_liodetach() need the same treatment?
| > >
| > > Yes, I had that in the original. I updated that and optimized
| > > the knl to just get the structure needed.
| > >
| > > Index: vfs_aio.c
| > > ===
| > > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v
| > > retrieving revision 1.243.2.3.4.1
| > > diff -u -p -r1.243.2.3.4.1 vfs_aio.c
| > > --- vfs_aio.c 21 Dec 2010 17:09:25 - 1.243.2.3.4.1
| > > +++ vfs_aio.c 27 Jan 2012 17:35:47 -
| > > @@ -2508,10 +2508,12 @@ filt_aioattach(struct knote *kn)
| > > static void
| > > filt_aiodetach(struct knote *kn)
| > > {
| > > - struct aiocblist *aiocbe = kn->kn_ptr.p_aio;
| > > + struct knlist *knl = &kn->kn_ptr.p_aio->klist;
| > >
| > > - if (!knlist_empty(&aiocbe->klist))
| > > - knlist_remove(&aiocbe->klist, kn, 0);
| > > + knl->kl_lock(knl->kl_lockarg);
| > > + if (!knlist_empty(knl))
| > > + knlist_remove(knl, kn, 1);
| > > + knl->kl_unlock(knl->kl_lockarg);
| > > }
| > >
| > > /* kqueue filter function */
| > > @@ -2553,10 +2555,12 @@ filt_lioattach(struct knote *kn)
| > > static void
| > > filt_liodetach(struct knote *kn)
| > > {
| > > - struct aioliojob * lj = kn->kn_ptr.p_lio;
| > > + struct knlist *knl = &kn->kn_ptr.p_lio->klist;
| > It is easy to be style-compiant there and move initialization of knl
| > after the blank line.
| >
| > Do you need two different functions now ? I think you can leave just one.
|
| Hmm, I think p_lio != p_aio, so two functions are required.
Correct, even thought they are together in a union, the structures are
different so klist would have a different offset for each function.
| I think the patch looks fine. The style fix to not assign 'knl' in its
| declaration would be nice to fix as you suggested, but that's minor.
Here is the updated version that seems to work fine.
Index: vfs_aio.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v
retrieving revision 1.243.2.3.4.1
diff -u -p -r1.243.2.3.4.1 vfs_aio.c
--- vfs_aio.c 21 Dec 2010 17:09:25 - 1.243.2.3.4.1
+++ vfs_aio.c 27 Jan 2012 18:22:10 -
@@ -2508,10 +2508,13 @@ filt_aioattach(struct knote *kn)
static void
filt_aiodetach(struct knote *kn)
{
- struct aiocblist *aiocbe = kn->kn_ptr.p_aio;
+ struct knlist *knl;
- if (!knlist_empty(&aiocbe->klist))
- knlist_remove(&aiocbe->klist, kn, 0);
+ knl = &kn->kn_ptr.p_aio->klist;
+ knl->kl_lock(knl->kl_lockarg);
+ if (!knlist_empty(knl))
+ knlist_remove(knl, kn, 1);
+ knl->kl_unlock(knl->kl_lockarg);
}
/* kqueue filter function */
@@ -2553,10 +25
Re: knlist_empty locking fix
Andrew Boyer writes:
| On Jan 27, 2012, at 12:15 PM, Doug Ambrisko wrote:
|
| > John Baldwin writes:
| > | Agreed, I think the missing locking should just be added to the aio code.
| >
| > Okay so then just:
| >
| > Index: vfs_aio.c
| > ===
| > RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v
| > retrieving revision 1.243.2.3.4.1
| > diff -u -p -r1.243.2.3.4.1 vfs_aio.c
| > --- vfs_aio.c 21 Dec 2010 17:09:25 - 1.243.2.3.4.1
| > +++ vfs_aio.c 27 Jan 2012 17:07:11 -
| > @@ -2509,9 +2509,12 @@ static void
| > filt_aiodetach(struct knote *kn)
| > {
| > struct aiocblist *aiocbe = kn->kn_ptr.p_aio;
| > + struct knlist *knl = &aiocbe->klist;
| >
| > - if (!knlist_empty(&aiocbe->klist))
| > - knlist_remove(&aiocbe->klist, kn, 0);
| > + knl->kl_lock(knl->kl_lockarg);
| > + if (!knlist_empty(knl))
| > + knlist_remove(knl, kn, 1);
| > + knl->kl_unlock(knl->kl_lockarg);
| > }
| >
| > /* kqueue filter function */
| >
| > I was trying to be consistant with knlist_remove but this is a much
| > smaller change that can be merge to older branches.
|
| Does filt_liodetach() need the same treatment?
Yes, I had that in the original. I updated that and optimized
the knl to just get the structure needed.
Index: vfs_aio.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v
retrieving revision 1.243.2.3.4.1
diff -u -p -r1.243.2.3.4.1 vfs_aio.c
--- vfs_aio.c 21 Dec 2010 17:09:25 - 1.243.2.3.4.1
+++ vfs_aio.c 27 Jan 2012 17:35:47 -
@@ -2508,10 +2508,12 @@ filt_aioattach(struct knote *kn)
static void
filt_aiodetach(struct knote *kn)
{
- struct aiocblist *aiocbe = kn->kn_ptr.p_aio;
+ struct knlist *knl = &kn->kn_ptr.p_aio->klist;
- if (!knlist_empty(&aiocbe->klist))
- knlist_remove(&aiocbe->klist, kn, 0);
+ knl->kl_lock(knl->kl_lockarg);
+ if (!knlist_empty(knl))
+ knlist_remove(knl, kn, 1);
+ knl->kl_unlock(knl->kl_lockarg);
}
/* kqueue filter function */
@@ -2553,10 +2555,12 @@ filt_lioattach(struct knote *kn)
static void
filt_liodetach(struct knote *kn)
{
- struct aioliojob * lj = kn->kn_ptr.p_lio;
+ struct knlist *knl = &kn->kn_ptr.p_lio->klist;
- if (!knlist_empty(&lj->klist))
- knlist_remove(&lj->klist, kn, 0);
+ knl->kl_lock(knl->kl_lockarg);
+ if (!knlist_empty(knl))
+ knlist_remove(knl, kn, 1);
+ knl->kl_unlock(knl->kl_lockarg);
}
/* kqueue filter function */
Thanks,
Doug A.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: knlist_empty locking fix
John Baldwin writes:
| On Friday, January 27, 2012 3:56:56 am Kostik Belousov wrote:
| > On Thu, Jan 26, 2012 at 01:03:26PM -0800, Doug Ambrisko wrote:
| > > Ran into problems with running kqueue/aio with WITNESS etc. Sometimes
| > > things are locked sometimes not. knlist_remove is called telling it
| > > whether it is locked or not ie:
| > >extern voidknlist_remove(struct knlist *knl, struct knote *kn,
| int islocked);
| > > so I changed:
| > > extern int knlist_empty(struct knlist *knl);
| > > to:
| > > extern int knlist_empty(struct knlist *knl, int islocked);
| > >
| > > and then updated things to reflect that following what that state of the
| > > lock for knlist_remove. If it is not locked, it gets a lock and
| > > frees it after.
| > >
| > > This now fixes a panic when a process using kqueue/aio is killed on
| > > shutdown with WITNESS.
| > >
| > > It changes an API/ABI so it probably can't merged back. If there are
| > > no objections then I'll commit it.
| > >
| > Change to knlist_init() does not make sense at all, the knlist shall
| > not be exposed to other consumers during initialization, so no need
| > to exclude the parallel access.
| >
| > Regarding the knlist_empty(), I propose to keep it as is. Locking
| > the knlist inside knlist_empty() does not make sense, because lock
| > is immediately dropped afterward, and relocked for remove. This way,
| > the entry could be removed from the list meantime (can it, really ?).
| >
| > I think that you should take a lock around the whole if() {} statement,
| > and call knlist_remove with locked == 1.
|
| Agreed, I think the missing locking should just be added to the aio code.
Okay so then just:
Index: vfs_aio.c
===
RCS file: /usr/local/cvsroot/freebsd/src/sys/kern/vfs_aio.c,v
retrieving revision 1.243.2.3.4.1
diff -u -p -r1.243.2.3.4.1 vfs_aio.c
--- vfs_aio.c 21 Dec 2010 17:09:25 - 1.243.2.3.4.1
+++ vfs_aio.c 27 Jan 2012 17:07:11 -
@@ -2509,9 +2509,12 @@ static void
filt_aiodetach(struct knote *kn)
{
struct aiocblist *aiocbe = kn->kn_ptr.p_aio;
+ struct knlist *knl = &aiocbe->klist;
- if (!knlist_empty(&aiocbe->klist))
- knlist_remove(&aiocbe->klist, kn, 0);
+ knl->kl_lock(knl->kl_lockarg);
+ if (!knlist_empty(knl))
+ knlist_remove(knl, kn, 1);
+ knl->kl_unlock(knl->kl_lockarg);
}
/* kqueue filter function */
I was trying to be consistant with knlist_remove but this is a much
smaller change that can be merge to older branches.
Thanks,
Doug A.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
knlist_empty locking fix
Ran into problems with running kqueue/aio with WITNESS etc. Sometimes
things are locked sometimes not. knlist_remove is called telling it
whether it is locked or not ie:
extern voidknlist_remove(struct knlist *knl, struct knote *kn, int
islocked);
so I changed:
extern int knlist_empty(struct knlist *knl);
to:
extern int knlist_empty(struct knlist *knl, int islocked);
and then updated things to reflect that following what that state of the
lock for knlist_remove. If it is not locked, it gets a lock and
frees it after.
This now fixes a panic when a process using kqueue/aio is killed on
shutdown with WITNESS.
It changes an API/ABI so it probably can't merged back. If there are
no objections then I'll commit it.
Here is the patch:
Index: fs/fifofs/fifo_vnops.c
===
RCS file: /cvs/src/sys/fs/fifofs/fifo_vnops.c,v
retrieving revision 1.157
diff -u -p -r1.157 fifo_vnops.c
--- fs/fifofs/fifo_vnops.c 16 Aug 2011 20:07:47 - 1.157
+++ fs/fifofs/fifo_vnops.c 26 Jan 2012 20:50:31 -
@@ -324,7 +324,7 @@ filt_fifordetach(struct knote *kn)
SOCKBUF_LOCK(&so->so_rcv);
knlist_remove(&so->so_rcv.sb_sel.si_note, kn, 1);
- if (knlist_empty(&so->so_rcv.sb_sel.si_note))
+ if (knlist_empty(&so->so_rcv.sb_sel.si_note, 1))
so->so_rcv.sb_flags &= ~SB_KNOTE;
SOCKBUF_UNLOCK(&so->so_rcv);
}
@@ -352,7 +352,7 @@ filt_fifowdetach(struct knote *kn)
SOCKBUF_LOCK(&so->so_snd);
knlist_remove(&so->so_snd.sb_sel.si_note, kn, 1);
- if (knlist_empty(&so->so_snd.sb_sel.si_note))
+ if (knlist_empty(&so->so_snd.sb_sel.si_note, 1))
so->so_snd.sb_flags &= ~SB_KNOTE;
SOCKBUF_UNLOCK(&so->so_snd);
}
Index: kern/kern_event.c
===
RCS file: /cvs/src/sys/kern/kern_event.c,v
retrieving revision 1.146
diff -u -p -r1.146 kern_event.c
--- kern/kern_event.c 16 Sep 2011 13:58:51 - 1.146
+++ kern/kern_event.c 26 Jan 2012 20:50:31 -
@@ -1650,7 +1650,7 @@ kqueue_close(struct file *fp, struct thr
KASSERT(kq->kq_refcnt == 1, ("other refs are out there!"));
fdp = kq->kq_fdp;
- KASSERT(knlist_empty(&kq->kq_sel.si_note),
+ KASSERT(knlist_empty(&kq->kq_sel.si_note, 1),
("kqueue's knlist not empty"));
for (i = 0; i < kq->kq_knlistsize; i++) {
@@ -1735,7 +1735,7 @@ kqueue_wakeup(struct kqueue *kq)
if (!SEL_WAITING(&kq->kq_sel))
kq->kq_state &= ~KQ_SEL;
}
- if (!knlist_empty(&kq->kq_sel.si_note))
+ if (!knlist_empty(&kq->kq_sel.si_note, 1))
kqueue_schedtask(kq);
if ((kq->kq_state & KQ_ASYNC) == KQ_ASYNC) {
pgsigio(&kq->kq_sigio, SIGIO, 0);
@@ -1867,10 +1867,18 @@ knlist_remove_inevent(struct knlist *knl
}
int
-knlist_empty(struct knlist *knl)
+knlist_empty(struct knlist *knl, int knlislocked)
{
- KNL_ASSERT_LOCKED(knl);
- return SLIST_EMPTY(&knl->kl_list);
+ int error;
+
+ KNL_ASSERT_LOCK(knl, knlislocked);
+ if (!knlislocked)
+ knl->kl_lock(knl->kl_lockarg);
+ error = SLIST_EMPTY(&knl->kl_list);
+ if (!knlislocked)
+ knl->kl_unlock(knl->kl_lockarg);
+
+ return error;
}
static struct mtx knlist_lock;
@@ -1931,7 +1939,9 @@ knlist_init(struct knlist *knl, void *lo
else
knl->kl_assert_unlocked = kl_assert_unlocked;
+ knl->kl_lock(knl->kl_lockarg);
SLIST_INIT(&knl->kl_list);
+ knl->kl_unlock(knl->kl_lockarg);
}
void
Index: kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.358
diff -u -p -r1.358 uipc_socket.c
--- kern/uipc_socket.c 25 Aug 2011 15:51:54 - 1.358
+++ kern/uipc_socket.c 26 Jan 2012 20:50:31 -
@@ -3188,7 +3188,7 @@ filt_sordetach(struct knote *kn)
SOCKBUF_LOCK(&so->so_rcv);
knlist_remove(&so->so_rcv.sb_sel.si_note, kn, 1);
- if (knlist_empty(&so->so_rcv.sb_sel.si_note))
+ if (knlist_empty(&so->so_rcv.sb_sel.si_note, 1))
so->so_rcv.sb_flags &= ~SB_KNOTE;
SOCKBUF_UNLOCK(&so->so_rcv);
}
@@ -3222,7 +3222,7 @@ filt_sowdetach(struct knote *kn)
SOCKBUF_LOCK(&so->so_snd);
knlist_remove(&so->so_snd.sb_sel.si_note, kn, 1);
- if (knlist_empty(&so->so_snd.sb_sel.si_note))
+ if (knlist_empty(&so->so_snd.sb_sel.si_note, 1))
so->so_snd.sb_flags &= ~SB_KNOTE;
SOCKBUF_UNLOCK(&so->so_snd);
}
Index: kern/vfs_aio.c
===
RCS file: /cvs/src/sys/kern/vfs_aio.c,v
retrieving revision 1.249
diff -u -p -r1.249 vfs_aio.c
--- kern/vfs_aio.c 16 Sep 2011 13:58:51 - 1.249
+++ kern/vfs_aio.c 26
Re: LSI 9240-8i (IBM M1015) MegaRaid support
Roberto de Iriarte writes: | Hi, | | Is there any expectancy of getting this piece of hardware (or it's IBM | silbing, the M1015) working in MegaRaid mode, without having to reflash | the card to IT mode. | | The reason of this request is that the UEFI Bios on the IBM XSeries | 3550M3 refuses to properly initialize the controller if reflashed with | the IT mode firmware, thus making it unusable. | | A search on LSI's website for a driver that supports 8-Stable or 9 did | not produce any results I have driver changes from LSI to support the 9240 and newer ThunderBolt based cards. I have the cards working but need to do a bunch more work to get this into shape to commit to FreeBSD. I also need to look at how they are dealing with their JBOD configuration and attachment. I have cards to test this stuff out but my time is limited to work on it. One thing I should start working on is merging in the LSI changes into the FreeBSD version since the LSI code drop has removed a bunch of features that the FreeBSD version has. Then I can have a smaller change. There are some architectural changes that I need to figure out. They started to use 64 bit addressing. Then there are style issues. Probably the best thing for me to do is add the new HW support to FreeBSD as a small diff then work on improving that and maybe others can also help with that. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: graid hit the tree
Alex Dupre writes: | Alexander Motin ha scritto: | > You can choose. Their functionality is comparable, but with graid: | ... | | Yes, as I supposed, so the answer is 'yes'. Obviously it needs a lot of | testing. Thanks for your work. Yes, it can use more testing which is why we (Cisco) wanted it in the tree. However, our experience has been very positive in performance and reliability. It has passed some of our harder failure tests of which others fail (race conditions of changing data while a rebuild is happening etc.). Now I don't have to maintain our hacked together ata and ata-raid changes :-) We are very happy to see this get into mainstream FreeBSD so others can help find and fix problems. It's very nice that it can work on any type of drives and not be tied to ata disks. This means it can/could work with scsi controllers with sw raid bios extensions etc. We have been testing it with ahci and and cam attached ata disks. If the hw supports it, it can update status leds. ata/ata-raid has served us well but graid will take us into the future! It was designed from the start as something that could be extended and deal with various failure modes. A big thanks to Alexander, Warner, iXsystems and Cisco for making this happen. It was Scott's vision a few years ago and now it is a reality. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Panic with locks and networking as of a day ago
I'm getting this panic a fair amount when dhclient is running on with the an(4) driver. My Atheros based card appears to have broke so I can't use that now (it doesn't work in Windows either). Here is the dmesg: lock order reversal 1st 0xc2ebaf08 vm object (vm object) @ vm/swap_pager.c:1319 2nd 0xc0735600 swap_pager swhash (swap_pager swhash) @ vm/swap_pager.c:1835 3rd 0xc103565c vm object (vm object) @ vm/uma_core.c:876 Stack backtrace: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0595952 stack pointer = 0x10:0xd0135a40 frame pointer = 0x10:0xd0135afc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 854 (ssh) trap number = 12 panic: page fault syncing disks, buffers remaining... panic: sleeping thread (pid 854) owns a mute x Uptime: 10m22s Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 and the trace is: kgdb) where #0 doadump () at ../../../kern/kern_shutdown.c:240 #1 0xc050f61c in boot (howto=260) at ../../../kern/kern_shutdown.c:372 #2 0xc050f9a7 in panic () at ../../../kern/kern_shutdown.c:550 #3 0xc05057db in propagate_priority (td=0x0) at ../../../kern/kern_mutex.c:124 #4 0xc0505fe9 in _mtx_lock_sleep (m=0xc072a76c, opts=0, file=0xc06aa995 "../../../netinet/tcp_timer.c", line=489) at ../../../kern/kern_mutex.c:635 #5 0xc0505a37 in _mtx_lock_flags (m=0xc072a76c, opts=0, file=0xc06aa995 "../../../netinet/tcp_timer.c", line=489) at ../../../kern/kern_mutex.c:333 #6 0xc05a1f10 in tcp_timer_rexmt (xtp=0xc3116164) at ../../../netinet/tcp_timer.c:489 #7 0xc051fea8 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:225 #8 0xc04fb802 in ithread_loop (arg=0xc16c1c80) at ../../../kern/kern_intr.c:540 #9 0xc04fa804 in fork_exit (callout=0xc04fb670 , arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:793 (kgdb) I have the core so I can run other commands if needed. BTW before that update to -current I was getting panics when I would insert or remove a card. Dhclient would end up being the process running and the kernel would crash in in_pcbconnect_setup when it did this check: if (ro->ro_rt && !(ro->ro_rt->rt_ifp->if_flags & IFF_LOOPBACK)) The ro->ro_rt->rt_ifp would be pointing the the ifp that was gone and panic. This one wasn't to bad except for crashing during a suspend/ resume sequence the other panic is happening randomly through the day. Hopefully someone can shed some light on this. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jumbograms (& em) & nfs a no go
Michal Mertl writes: | On Thu, 30 Oct 2003, Sam Leffler wrote: | | > On Thursday 30 October 2003 04:46 am, Michal Mertl wrote: | > > I wanted to test gigabit network performance and found out that current | > > (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU | > > set to 6000), Intel adapters and nfs (both UDP and TCP). | > > | > > I checked that the same thing works with 4.9. | > > | > > I then left one computer at 4.9 and upgraded the other to 5.0. When I | > > mount a partition from 5.0 machine I found out, that copying reliably | > > works only from 5.0 to 4.9. The other way around I see messages 'em0: | > > discard oversize frame (ether type 800 flags 3 len 67582 > max 6014)' on | > > 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server | > > 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can | > > be revived by changing mtu back to 1500 and down/up sequence. | > | > I've ran many jumbogram tests of machines connected with a cross-over cable | > and em devices at each end. If you've got a swtch in the middle make sure it | > does the right thing. | | I also used exclusively crossover cable. The same configuration worked | with 4.9. The problem appears only with NFS. You might want to try this patch: Index: if_em.c === RCS file: /cvs/src/sys/dev/em/if_em.c,v retrieving revision 1.32 diff -c -r1.32 if_em.c *** if_em.c 15 Oct 2003 05:34:41 - 1.32 --- if_em.c 30 Oct 2003 19:39:49 - *** *** 2454,2460 BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ MCLBYTES,/* maxsize */ !1, /* nsegments */ MCLBYTES,/* maxsegsize */ BUS_DMA_ALLOCNOW,/* flags */ NULL,/* lockfunc */ --- 2454,2460 BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ MCLBYTES,/* maxsize */ !2, /* nsegments */ MCLBYTES,/* maxsegsize */ BUS_DMA_ALLOCNOW,/* flags */ NULL,/* lockfunc */ There was a few bugs in the system before in that there was insufficient error check in the bus_dma stuff. The issue was that HW was writing more then was the allocated due to (nsegments=1). This isn't the right fix but might help point to the issue. I don't have access to the HW to test it out anymore. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: an driver / Cisco Aironet 340 stopped working
Tomi Vainio - Sun Finland writes: | Doug Ambrisko writes: | > | > I assume you are using a pccard version. | > | > It only a problem newer firmware. It works ... just noisy! | > | > You can try this patch to -current that should make it quiet. | > There is a bug with -current and setting the TX speed that I need | > to work on. Looks like things changed in the wlan module. | > I may commit this but there is an issue with the mpi-350 support. | > They changed the programing paradigm and after 14 packets the | > TX engine stalls. I'm still working on tweaks to that. | > I had hoped to get that working and commit all of this. | > | > Let me know how this works. It should just work. | > | I was ready to say that it's not working but then ipv6 came up | automatically. I didn't look this before but now it looks that | dhclient don't get address but if manually set v4 address it works. | I've to check how it works with older kernel because until now I only | checked that I didn't get address from dhcp. There have been some changes to dhclient (link detection) that might have some interaction side effects. Not blaming dhclient but that is something to be aware of. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: an driver / Cisco Aironet 340 stopped working
Tomi Vainio - Sun Finland writes: | Peter Radcliffe writes: | > Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> probably said: | > > Peter Radcliffe writes: | > > > Cisco have changed the operation of the card with newer firmware and | > > > havn't released docs on working with the newer firmware. | > | > > I've tried multiple old firmwares and this loader.conf tweak but no | > > luck yet. Can you say what was the last working firmware? | > | > I don't have any 340 cards, just 350 cards, so no. | > | Firmware files are the same for both cards or that's my thought from | this filename. | | 350-340-PCMCIA-LMC-PCI-v52017.exe I think he is confusing pccard versus mini-pci cards. All pccard cards (4800/340/350) use the same firmware. I have a mix of them. The mini-pci which is currently only a 350 uses totally different firmware. It's the newer 350 firmware that I'm having trouble figuring out how to make it work properly. The older mini-pci firmware works okay. Doug A. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: an driver / Cisco Aironet 340 stopped working
Tomi Vainio - Sun Finland writes:
| I've used my Cisco WLAN with Toshiba Portege 3440 couple years but now
| it's broken. I just upgraded to new Toshiba Tecra M1 and reinstalled
| FreeBSD there and now I get "an0: record length mismatch -- expected
| 430, got 440 for Rid ff68" errors. I already tried with old laptop
| with latest kernel and old kernel from Jun 26th but it's also broken
| there so I cannot say who long this has been broken.
I assume you are using a pccard version.
It only a problem newer firmware. It works ... just noisy!
You can try this patch to -current that should make it quiet.
There is a bug with -current and setting the TX speed that I need
to work on. Looks like things changed in the wlan module.
I may commit this but there is an issue with the mpi-350 support.
They changed the programing paradigm and after 14 packets the
TX engine stalls. I'm still working on tweaks to that.
I had hoped to get that working and commit all of this.
Let me know how this works. It should just work.
Doug A.
Index: sys/dev/an/if_aironet_ieee.h
===
RCS file: /cvs/src/sys/dev/an/if_aironet_ieee.h,v
retrieving revision 1.11
diff -c -r1.11 if_aironet_ieee.h
*** sys/dev/an/if_aironet_ieee.h29 Dec 2002 19:22:06 - 1.11
--- sys/dev/an/if_aironet_ieee.h19 Aug 2003 02:41:06 -
***
*** 63,69
* data, which is 240 words long, so 256 should be a safe
* value.
*/
! #define AN_MAX_DATALEN512
struct an_req {
u_int16_t an_len;
--- 63,69
* data, which is 240 words long, so 256 should be a safe
* value.
*/
! #define AN_MAX_DATALEN4096
struct an_req {
u_int16_t an_len;
***
*** 261,267
u_int32_t an_uptime_usecs;/* 0x178 */
u_int32_t an_uptime_secs; /* 0x17C */
u_int32_t an_lostsync_better_ap; /* 0x180 */
! u_int32_t an_rsvd[10];
};
/*
--- 261,267
u_int32_t an_uptime_usecs;/* 0x178 */
u_int32_t an_uptime_secs; /* 0x17C */
u_int32_t an_lostsync_better_ap; /* 0x180 */
! u_int32_t an_rsvd[15];
};
/*
***
*** 337,342
--- 337,343
u_int8_tan_magic_packet_action; /* 0x98 */
u_int8_tan_magic_packet_ctl;/* 0x99 */
u_int16_t an_rsvd9;
+ u_int16_t an_spare[13];
};
#define AN_OPMODE_IBSS_ADHOC 0x
***
*** 417,422
--- 418,435
charan_ssid3[32];
};
+ struct an_ltv_ssid_entry{
+ u_int16_t an_len;
+ charan_ssid[32];
+ };
+
+ #define MAX_SSIDS 25
+ struct an_ltv_ssidlist_new {
+ u_int16_t an_len;
+ u_int16_t an_type;
+ struct an_ltv_ssid_entry an_entry[MAX_SSIDS];
+ };
+
/*
* Valid AP list.
*/
***
*** 501,507
u_int16_t an_softcaps;/* 0x7C */
u_int16_t an_bootblockrev;/* 0x7E */
u_int16_t an_req_hw_support; /* 0x80 */
! u_int16_t an_unknown; /* 0x82 */
};
/*
--- 514,520
u_int16_t an_softcaps;/* 0x7C */
u_int16_t an_bootblockrev;/* 0x7E */
u_int16_t an_req_hw_support; /* 0x80 */
! u_int16_t an_unknown[31]; /* 0x82 */
};
/*
***
*** 580,586
u_int8_tan_avg_noise_prev_min_db; /* 0x7D */
u_int8_tan_max_noise_prev_min_pc; /* 0x7E */
u_int8_tan_max_noise_prev_min_db; /* 0x7F */
! u_int16_t an_spare[5];
};
#define AN_STATUS_OPMODE_CONFIGURED 0x0001
--- 593,599
u_int8_tan_avg_noise_prev_min_db; /* 0x7D */
u_int8_tan_max_noise_prev_min_pc; /* 0x7E */
u_int8_tan_max_noise_prev_min_db; /* 0x7F */
! u_int16_t an_spare[8];
};
#define AN_STATUS_OPMODE_CONFIGURED 0x0001
Index: sys/dev/an/if_an.c
===
RCS file: /cvs/src/sys/dev/an/if_an.c,v
retrieving revision 1.51
diff -c -r1.51 if_an.c
*** sys/dev/an/if_an.c 28 Jun 2003 06:13:27 - 1.51
--- sys/dev/an/if_an.c 19 Aug 2003 02:41:06 -
***
*** 313,319
device_tdev;
{
struct an_softc *sc = device_get_softc(dev);
! struct an_ltv_ssidlist ssid;
int error;
bzero((char *)&ssid, sizeof(ssid));
--
Re: pptp mpd under 5.0
Aaron Wohl writes: | Im trying to run pptp under 5.0 -current. (first time with mpd so | probably some config issue) | | I get these errors: | mpd: pid 1102, version 3.13 ([EMAIL PROTECTED] 09:35 | 17-Mar-2003) | [pptp0] can't create socket node: No such file or directory | mpd: local IP address for PPTP is 10.23.0.3 | [pptp0] using interface | [pptp1] can't create socket node: No such file or directory | [pptp1] using interface | | I tried running mpd under truss to see what its trying to access... im | guessing its missing a tun0 or ng0 or some such from /dev, whats the | replacement for MAKDEV to mkae them? ... and I cant seem to get truss to | run at all on any program... | bash-2.05b# truss mpd | truss: cannot open /proc/curproc/mem: No such file or directory | truss: cannot open /proc/1107/mem: No such file or directory | bash-2.05b# Just a hint. /sys/modules/netgraph/mppc/Makefile and take out the stuff about rc4. When rc4 was made into a module this needed to be removed from mppc. This was done around 5.0 in -current but I forget if it was in 5.0 or not. I did fix this in -current. Then again you might have a totally different problem. I do have it working in -current (for some value of current). Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: help: can't boot 5.0 diskless
Dong Lin writes: | | Hi, I have been running etherboot/diskless machines successfully with | several 4.x releases. Now I have trouble bringing up 5.0 diskless x86 | machines. The same dhcp/nfs/etherboot setup works for 4.x. But the 5.0 | kernel freezes and eventually crashes without printing anything on the | console. I am pretty sure it has passed the etherboot stage, network | traces showed that init was loaded via NFS. If I replace the 5.0 | kernel with a 4.7 image, it simply works. | | Can someone tell me what different things I have to do in a diskless | 5.0 kernel? I do have the BOOTP, BOOTP_* and NFS_ROOT options enabled. | | Thanks for your help, Remember to compile in the hints into the 5.X kernel. The loader PXE/disk loaders do that for you but Etherboot doesn't. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CVSup Delete failures
Michael Sierchio writes: | Forrest Aldrich wrote: | > FYI, over the last few days, I've been seeing this error while doing a | > CVSUP of the code for both FreeBSD-STABLE (4.7) and Current: | > | > Delete src/contrib/gcc/INSTALL | > Cannot delete "/usr/local/src/freebsd/5.0/src/contrib/gcc/INSTALL": | > Directory not empty The problem seems to be an INSTALL directory now in HEAD and a file in Attic/INSTALL. cvs co of -stable is also barfing on this conflict of the old file and new directory.o U src/contrib/gcc/xcoffout.c U src/contrib/gcc/xcoffout.h cvs [checkout aborted]: could not chdir to src/contrib/gcc/INSTALL: Not a directory a21p% Removing the INSTALL directory in my local repo fixes the issue for -stable. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unable to use boot0cfg
David Wolfskill writes: | 0:ad(0,1,a)/boot/loader ... or put that in /boot.config on the / that boot0 defaults to boot. a21p% cat /boot.config 0:ad(0,2,a)/boot/loader a21p% ls -l /boot.co* Then just change it. It does mean that in my setup if I'm running -current I have to edit /stable/boot.config since boot0 always boots my -stable area. | (to boot from slice 1) -- ref. "man boot". Your welcome. I submitted that man page update to ru after finding that secret feature in the source code. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: acpid implementation?
Frode Nordahl writes: | On Fri, 2002-11-08 at 22:23, Hiten Pandya wrote: | > On Wed, Nov 06, 2002 at 10:27:47PM +0100, Frode Nordahl wrote the words in effect |of: | > > Hello, | > > | > > I have been searching mailing lists and my friend Google for information | > > about a acpid (like apmd) implementation for FreeBSD, but I have found | > > nothing. | > > | > > Does one exist anywhere, or has anyone started out on something without | > > telling anyone? :) | > | > Why do you need an acpid? | misc stuff | | instruct dhclient to get a new lease on resume (maybe free it on sleep), | try to configure wlan if no link detected on ethernet etc. | | I put my computer to sleep instead of turning it of most of the time, | and having to run "killall dhclient; dhclient dc0" every time I resume | it after coming home / go to work is a bit annoying :) | | I'm sure people have this and other things they want to configure their | computer to do on sleep / resume. Exactly. My usage model is done at work put my laptop to sleep and go home. At home I resume it and it sync's up to any network it finds with the appropriate security bits. I put it to sleep before going to work and resume at work. I also have generic modes. I install different firewall rules depending on where I'm at. I also run a local name server that needs to get updated. Then there is YP, amd, etc. that need configuring. Actually it would be kind-of cool to do a network stop/network start on suspend/resume. Maybe in RCng??? Also I have some apps that need to be stopped and started. Like ssh's that can't work now that the network has changed. With 802.11 resuming and seeking out the right network is so usefull. My laptup is up for days/months before reboots but my uptime is lower due to sleeping. This is one reason I don't run -current on my laptop. Other problems are being resolved slowly but things are looking good. Now devd should solve most of my suspend/resume issues with PCMCIA cards but not with built-in 802.11 stuff. Maybe devd can take over for as an apmd replacement? Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Expensive timeout(9) function" @an_stats_update() [/usr/src/sys/dev/an/if_an.c:724]
David Wolfskill writes:
| Noticed a bunch of:
| > Expensive timeout(9) function: 0xc0170e40(0xc274c000) 0.001114387
|
| from running (yesterday's) -CURRENT, so I thought I'd check against
| (yesterday's kernel.debug (before I replaced it with today's).
|
| I do have some patches to the "an" driver installed (from Doug Ambrisko)
| that don't seem to have been committed (yet?).
|
| If he (or anyone else) would like me to test things, I'm willing and
| able.
I haven't seen that but -current isn't being very stable on my laptop
so I have to keep going back to -stable for my job. I'm getting some
patches ready to commit. Need some work on the man page. It closes
a PR that was partially incomplete. You might want to get rid of
that old stuff and try this. The only timeout calls an_stats_update.
I don't really see why it would take a long time. Note this patch
doesn't touch that function so it shouldn't fix that problem.
Doug A.
Index: sys/dev/an/if_aironet_ieee.h
===
RCS file: /cvs/src/sys/dev/an/if_aironet_ieee.h,v
retrieving revision 1.10
diff -c -r1.10 if_aironet_ieee.h
*** sys/dev/an/if_aironet_ieee.h23 Sep 2002 18:54:29 - 1.10
--- sys/dev/an/if_aironet_ieee.h25 Oct 2002 03:33:33 -
***
*** 132,137
--- 132,156
};
#endif
+ /*
+ * The card provides an 8-bit signal strength value (RSSI), which can
+ * be converted to a dBm power value (or a percent) using a table in
+ * the card's firmware (when available). The tables are slightly
+ * different in individual cards, even of the same model. If the
+ * table is not available, the mapping can be approximated by dBm =
+ * RSSI - 100. This approximation can be seen by plotting a few
+ * tables, and also matches some info on the Intersil web site (I
+ * think they make the RF front end for the cards. However, the linux
+ * driver uses the approximation dBm = RSSI/2 - 95. I think that is
+ * just wrong.
+ */
+
+ struct an_rssi_entry {
+ u_int8_tan_rss_pct;
+ u_int8_tan_rss_dbm;
+ };
+
+
struct an_ltv_key {
u_int16_t an_len;
u_int16_t an_type;
***
*** 335,340
--- 354,360
#define AN_RXMODE_80211_MONITOR_ANYBSS0x0004
#define AN_RXMODE_LAN_MONITOR_CURBSS 0x0005
#define AN_RXMODE_NO_8023_HEADER 0x0100
+ #define AN_RXMODE_NORMALIZED_RSSI 0x0200
#define AN_RATE_1MBPS 0x0002
#define AN_RATE_2MBPS 0x0004
***
*** 503,508
--- 523,538
/* ??? */
};
+ /*
+ * RSSI map. If available in the card's firmware, this can be used to
+ * convert the 8-bit RSSI values from the card into dBm.
+ */
+ struct an_ltv_rssi_map {
+ u_int16_t an_len;
+ u_int16_t an_type;
+ struct an_rssi_entryan_entries[256];
+ };
+
/*
* Status (read only). Note: the manual claims this RID is 108 bytes
* long (0x6A is the last datum, which is 2 bytes long) however when
***
*** 520,526
u_int8_tan_macaddr[6]; /* 0x02 */
u_int16_t an_opmode; /* 0x08 */
u_int16_t an_errcode; /* 0x0A */
! u_int16_t an_cur_signal_strength; /* 0x0C */
u_int16_t an_ssidlen; /* 0x0E */
u_int8_tan_ssid[32];/* 0x10 */
u_int8_tan_ap_name[16]; /* 0x30 */
--- 550,556
u_int8_tan_macaddr[6]; /* 0x02 */
u_int16_t an_opmode; /* 0x08 */
u_int16_t an_errcode; /* 0x0A */
! u_int16_t an_signal_quality; /* 0x0C */
u_int16_t an_ssidlen; /* 0x0E */
u_int8_tan_ssid[32];/* 0x10 */
u_int8_tan_ap_name[16]; /* 0x30 */
***
*** 541,552
u_int16_t an_cur_signal_quality; /* 0x6C */
u_int16_t an_current_tx_rate; /* 0x6E */
u_int16_t an_ap_device; /* 0x70 */
! u_int16_t an_normalized_rssi; /* 0x72 */
u_int16_t an_short_pre_in_use;/* 0x74 */
u_int8_tan_ap_ip_addr[4]; /* 0x76 */
! u_int16_t an_max_noise_prev_sec; /* 0x7A */
! u_int16_t an_avg_noise_prev_min; /* 0x7C */
! u_int16_t an_max_noise_prev_min; /* 0x7E */
u_int16_t an_spare[5];
};
--- 571,585
u_int16_t an_cur_signal_quality; /* 0x6C */
Re: ste driver broken
Francois Tigeot writes: [ Charset ISO-8859-1 unsupported, converting... ] | Greetings, | | I recently upgraded one machine to a recent -CURRENT, and the NIC | (DLink 550 TX) fails to be properly initialized. | The rest of the system is pretty vanilla : Athlon XP, with Via chipset. | | | Here is the relevant part of dmesg: | | ste0: port 0x9800-0x987f mem 0xe900-0xe97f |irq 7 at device 11.0 on pci0 | /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from |/usr/src/sys/pci/if_ste.c:937 | /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from |/usr/src/sys/pci/if_ste.c:937 | lock order reversal | 1st 0xc25b69a4 ste0 (network driver) @ /usr/src/sys/pci/if_ste.c:937 | 2nd 0xc0318600 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:317 | /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from |/usr/src/sys/pci/if_ste.c:937 | /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from |/usr/src/sys/pci/if_ste.c:937 | /usr/src/sys/vm/uma_core.c:1332: could sleep with "ste0" locked from |/usr/src/sys/pci/if_ste.c:937 | ste0: Ethernet address: 00:50:ba:71:be:ea | ste0: MII without any phy! | device_probe_and_attach: ste0 attach returned 6 I'd like to send you some code to test out. It looks like a 550 is different from a 580 part. I need to do some testing. Thanks, Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: booting -current with etherboot?
Nicolas Souchu writes: | etherboot-5.0.3 doesn't boot my -current kernel. | | I previously had to upgrade the loader because of a similar problem when | booting a -current kernel with a -stable loader. | | What are exactly the differences? Etherboot boots a -stable kernel just fine. I'm using both 5.0.3 & just tried 5.0.4 and both work. Remember that you need to compile in the hints into the kernel. I just verified this netbooting FreeBSD inside vmware. # uname -a FreeBSD 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sat Dec 29 20:24:00 GMT 2001 ambrisko@a21p:/usr/src/sys/i386/compile/NETBOOT i386 # mount 192.168.254.1:/data/home/ambrisko/netboot on / (nfs) devfs on /dev (devfs, local) # swapinfo Device 512-blocks UsedAvail Capacity Type [NFS swap] 1308160 130816 0%Interleaved # In my kernel config I have: #To statically compile in device wiring instead of /boot/device.hints hints "NETBOOT.hints" #Default places to look for devices. My NETBOOT.hints is basically a copy of GENERIC.hints. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: *HEADS UP!* This means you!
Peter Wemm writes: | I for one will miss it. I used libexec/telnetd extensively during ia64 | bootstrap (and still use it) before we had the crypto stuff going. This | was all built by hand, 'make world' still isn't an option there. I also | use usr.bin/telnet on other systems where SRA is constantly getting in | my face and annoying the !^@#%!@^#!# out of me. Well, for the SRA thing you can do a "-X SRA" now that it doesn't core-dump if you do that (I submited that patch a year ago or so since it was pretty annoying!). I setup my telnetd servers with "-X SRA" so that I don't have to do it via command line. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Anyone experience problems with the "tap" device in current?
I just tried using tap in current. In both cases I don't see the /dev/tapX devices with devfs and accessing it without devfs doesn't work reporting "Device not configured". I tried it as a module and built into the kernel. Does anyone have this working? a2# ls /dev acd0a cuala1 pci ttyld1 ttyvb acd0c fd ppi0ttyp0 ttyvc ad0 fd0 ptyp0 ttyv0 ttyvd ata io random ttyv1 ttyve bpf0kbd0stderr ttyv2 ttyvf console klogstdin ttyv3 urandom consolectl kmemstdout ttyv4 usb cttylog sysmousettyv5 usb0 cuaa0 lpt0ttyd0 ttyv6 vga cuaa1 lpt0.ctlttyd1 ttyv7 zero cuaia0 mdctl ttyid0 ttyv8 cuaia1 mem ttyid1 ttyv9 cuala0 nullttyld0 ttyva a2# df /dev Filesystem 1K-blocks UsedAvail Capacity Mounted on devfs 110 100%/dev a2# kldstat Id Refs AddressSize Name 16 0xc000 4000 kernel 21 0xc13b1000 14000linux.ko 31 0xc13eb000 4000 if_tap.ko a2# Thanks, Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: ACPI CHANGES AFFECTING MOST -CURRENT USERS
Robert Watson writes: | On Wed, 29 Aug 2001, Garrett Wollman wrote: | > < said: | > > - I pushed the power button, and my system shut down cleanly! | > | > > Yes. ACPI brings some useful new features. 8) | > | > FSVO ``useful''. It's a real PITA to have to physically unplug the | > machine when the kernel is wedged rather than have the power button | > turn off the power. (The machine in question does not have a reset | > switch.) As a sometime developer, I may well have a reason to power | > the system off without performing any kind of shutdown. | | Most systems with soft power will perform a hard powerdown if you hold | down the power button for a sufficiently long period of time (10 - 20 | seconds). Correct ... and unfortunately it's done in hardware so you can trap it :-( In some applications you want to make it really hard for someone to be able to turn it off when a "power off" is not equivalent to "pull the plug" and the "pull the plug" is safer for the system due to power supply design. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bash in /usr/local/bin?
David O'Brien writes: | On Tue, Aug 14, 2001 at 01:23:40PM +0200, Johann Visagie wrote: | > if ( "$tty" != "" ) then | > | > (There may be a more elegant way to check for shell interactivity in csh, and | > if there is I'd like to know about it, please. :-) | | I've used "if ($?USER == 0 || $?prompt == 0)" in the past. I've used 'tty' to tell me for more info 'man tty'. a21p% echo hello | tty && echo hi not a tty a21p% tty && echo hi /dev/ttypg hi a21p% Don't know if this has been mentioned since I generally ignore things about bash. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for review... PR 25577
Brooks Davis writes: | On Mon, Apr 02, 2001 at 12:28:38PM -0700, Doug Ambrisko wrote: | > Well I can't see that since it's not an array and the values come | > from iterating through Cisco's API and a direct query for the | > transmit key. Look at ancontrol for the ugly & secret details! | | I'm pretty sure I've also managed to get it to reports things that just | plain aren't true like Bruce did. I've bitched to my Cisco rep again | to try and get better doc, but so far I haven't had much luck. I just | made a specific request for more data on setting and getting WEP keys. | In my patches, I just copied the stuff from ancontrol since that's all | we've got. The linux code is even more non-sensical then ancontrol in | that it reports five keys. FYI we've found a bug in ancontrol and the scheme for reporting keys if keys are not filled in order. It would be nice to get the source for the Linux configuration utilties that they distribute with the driver on the Cisco web site. I've tried to run it under Linux and I get "no radio found" although I can ping over the Aironet card! Linux and no source makes it hard to figure out what is happening. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for review... PR 25577
Bruce A. Mah writes: | 1. Seems like I needed to ifconfig the interface up before my other | commands would take effect. I don't recall needing to do any such | thing with the old driver before I could do ancontrol. Is this a | change in behavior or did I miss something? I fixed this and Archie put it in -current and after 4.3 goes out he should MFC it. In the interim try the patch at: http://www.ambrisko.com/doug/an.patch it has some new features such as enabling promiscuous mode from Allan Saddi! | WEP Key status: | Key 0 is set 40 bits | Key 1 is set 128 bits | Key 2 is set 40 bits | Key 3 is unset | The active transmit key is 2 | | If I had to guess, I'd say that if there is an array of WEP keys, the | programs are starting to read one key too late into the array when they | display them. There also seems to be a little disagreement as to | whether keys are numbered starting from 0 or 1. Well I can't see that since it's not an array and the values come from iterating through Cisco's API and a direct query for the transmit key. Look at ancontrol for the ugly & secret details! FYI from my laptop: WEP Key status: Key 0 is set 128 bits Key 1 is set 40 bits Key 2 is unset Key 3 is unset The active transmit key is 0 This corresponds to my Win 98 setting even when I twiddled things around and add things to verify it. It was a 1:1 mapping between the configuration utility and ancontrol. I'm also looking at running the Cisco for Linux configuration utilities under FreeBSD's Linux emulation. However, I can't get them to work under Linux (well I'm Linux challenged ... where's "make world"). I've heard they have lots of features but won't release the source for these utilities :-( Atleast the driver source is available so we should be able to emulate the Linux ioctls that they use :-) Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP **
Alfred Perlstein writes: | What about the BABUG meeting on Thursday? There's gonna be a film | crew from IBM-Linux there and a tutorial on netbooting. | | http://www.bafug.net/meetings/NextMeetingBerk.html Including netbooting of an Airport base station? run therboot or irport? >E ROM segment 0x8000 length 0x40EA reloc 0x9800 Boot from (N)etwork or from (L)ocal? N Etherboot/32 version 4.6.12 (GPL) for [NE2100] Probing...[NE2100] PCnet/ISA+ 79C961A base 0x0300, DMA 5, addr 00:30:65:3A:59:5F Searching for server (DHCP)... Me: 192.168.2.194, Server: 192.168.2.254, Gateway 192.168.2.254 Loading /tftpboot/kernel.bsd (ELF/FreeBSD)0680- 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 4.3-BETA #9: Wed Mar 21 15:41:11 PST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/AIRPORT Timecounter "i8254" frequency 1193182 Hz CPU: AMD Unknown (486-class CPU) Origin = "AuthenticAMD" Id = 0x4a4 Stepping = 4 Features=0x0 real memory = 4194304 (4096K bytes) avail memory = 1998848 (1952K bytes) Preloaded elf kernel "kernel" at 0xc025bb00. npx0: on motherboard npx0: 387 emulator isa0: on motherboard pcic0: at port 0x3e0 iomem 0xd on isa0 pcic0: Polling mode pccard0: on pcic0 pccard1: on pcic0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x30 on isa0 sio0: type 16550A, console lnc0 at port 0x300-0x317 iomem 0xd-0xd irq 10 on isa0 lnc0: PCnet-ISA II address 00:30:65:3a:59:5f lnc0: driver is using old-style compatability shims RTC BIOS diagnostic error e4 pccard: card inserted, slot 0 Sending DHCP Discover packet from interface lnc0 (00:30:65:3a:59:5f) Received DHCP Offer packet on lnc0 from 192.168.2.254 (accepted) (no root path) Sending DHCP Request packet from interface lnc0 (00:30:65:3a:59:5f) Received DHCP Ack packet on lnc0 from 192.168.2.254 (accepted) (got root path) lnc0 at 192.168.2.194 server 192.168.2.254 boot file /tftpboot/kernel.bsd router 192.168.2.254 rootfs 192.168.2.254:/usr/home/ambrisko/netboot swapfs 192.168.2.254:/usr/work/netboot Adjusted interface lnc0 md_lookup_swap: Swap size is 262144 KB Mounting root from nfs: NFS ROOT: 192.168.2.254:/usr/home/ambrisko/netboot NFS SWAP: 192.168.2.254:/usr/work/ij3/netboot wi0: at port 0x240-0x27f irq 5 slot 0 on pccard0 wi0: Ethernet address: 00:02:2d:09:4b:f2 pccardd[40]: Assigning I/O window 0, start 0x240, size 0x40 flags 0x5 pccardd[40]: Assign wi0, io 0x240-0x27f, mem 0x0, 0 bytes, irq 5, flags 0 pccardd[40]: wi0: Lucent Technologies (WaveLAN/IEEE) inserted. dhclient: New IP Address(wi0): 207.76.207.134 dhclient: New Subnet Mask (wi0): 255.255.255.0 dhclient: New Broadcast Address(wi0): 207.76.207.255 dhclient: New Routers: 207.76.207.254 pccardd[40]: pccardd started login: ROOT LOGIN (root) ON ttyp0 FROM crab login: ROOT LOGIN (root) ON ttyp1 FROM 207.76.207.135 Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
Warner Losh writes: | In message <[EMAIL PROTECTED]> Doug Ambrisko writes: | : Well this is what I'm doing with the Aironet stuff. I have a script | : to flip between modes until it sync's up. I bought the PCMCIA ISA | : adapter for $25 from a local surplus place. | | Does this mean that the an driver can operate in "base station" mode? No, just ad-hoc (atleast that's what is published). So on my laptop my script flips between modes (ad-hoc & infrastructure) until it sync's up with whatever it can find. I start it out of pccard.conf so it is automatic on card insertion, reboot or wakeup. | : BTW I saw ADDTRON http://www.addtron.com/ has a base station for around | : $220 that can do 128 bit encryption, has an antenna and is Web administered. | : I haven't used it but it looks interesting. | | I'll have to check this out as well. Let us know what you find out. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
Wes Peters writes: | Warner Losh wrote: | > | > In message <[EMAIL PROTECTED]> Wes Peters writes: | > : Dell is selling a Lucent-OEMed card for $139. I don't know if it is a | > : Silver or Gold, though. | > | > http://www.comready.com/dlindwwirlan.html | > | > is selling what appears to be a lucentOEM'd card for $119. It has | > 40-bit WEP, so I don't know what metal that makes it (despite having | > been told the last time this came up). | | Silver, according to the wicontrol(8) man page. ;^) | | > There's no external antenna | > connector, however. Still not a bad price and with $20 of the price | > point for taking my whole house wireless. | | Yeah, thanks. I still haven't decided if I'm going to stick (another) | wireless card in my gateway machine or buy an access point/bridge. The | prices of PCMCIA card cages are frightfully high, making the cost roughly | the same, and the access point would support infrastructure mode also. Well this is what I'm doing with the Aironet stuff. I have a script to flip between modes until it sync's up. I bought the PCMCIA ISA adapter for $25 from a local surplus place. BTW I saw ADDTRON http://www.addtron.com/ has a base station for around $220 that can do 128 bit encryption, has an antenna and is Web administered. I haven't used it but it looks interesting. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tcsh bug
David O'Brien writes: | On Mon, Apr 24, 2000 at 04:04:00PM -0700, Doug Ambrisko wrote: | > With -current as of the weekend. I now have tcsh as the root shell. | > I noticed something "strange", my history only displays the time, for example | | Known problem. Will be fixed in a few days. Thanks, let me know when it should be okay. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
tcsh bug
Not to create another argument but tcsh does not appear to be csh :-( With -current as of the weekend. I now have tcsh as the root shell. I noticed something "strange", my history only displays the time, for example dual# history 1 13:42 2 13:42 3 13:42 4 13:42 5 13:42 6 13:43 7 13:43 8 13:43 9 13:43 10 13:43 11 15:35 12 15:35 13 15:36 14 15:37 15 15:37 16 15:39 17 15:39 18 15:39 ... etc ... However, history does work with ! for example on the same machine right after the above history command: dual# !ech echo $SHELL /bin/csh dual# After I did a "make world" I also did a "make distribution" in /usr/src/etc to make sure I had default files. Here is the results of env: dual# env DISPLAY=770z.whistle.com:0.0 PRINTER=lp TERM=xterm PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/root/bin MAIL=/var/mail/root BLOCKSIZE=K FTP_PASSIVE_MODE=YES SHELL=/bin/csh HOME=/root LOGNAME=root USER=root HOSTTYPE=FreeBSD VENDOR=intel OSTYPE=FreeBSD MACHTYPE=i386 SHLVL=1 PWD=/root GROUP=wheel HOST=dual REMOTEHOST=192.168.1.30 EDITOR=vi PAGER=more dual# Here is the results from set: dual# set _ env addsuffix argv() cwd /root dirstack/root echo_style bsd edit filec gid 0 group wheel history 100 home/root loginsh mail/var/mail/root owd path(/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin /root/bin) prompt dual# prompt2 %R? prompt3 CORRECT>%R (y|n|e|a)? shell /bin/csh shlvl 1 status 0 tcsh6.09.01 termxterm tty ttyp0 uid 0 userroot version tcsh 6.09.01 (Astron) 2000-01-14 (i386-intel-FreeBSD) options 8b,nls,dl,al,sm,rh,color dual# This is from the root login. Please help ... I have trouble remembering what I type and the way I use history is to cut'n'paste via X. It's works and I don't have to remember various things that change when I'm forced to change shell so please no philosophy lessons. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Neat kernel development environment.
Poul-Henning Kamp writes: | In message <[EMAIL PROTECTED]>, Julian |El | ischer writes: | | >Oh? can you run a kernel in a jail for debugging? | | No, not quite yet, but what IBM bragged about the 41k linuxes for | was for what jails do for you. Nope not quite. Since you could actually crash the kernel in the VM/Linux session and the others are still going. Crash the kernel in a jail and all sessions are toast. Note I do like jail on FreeBSD one thing that would be nice with jail is if the IP address for the jail disappeared from the non-jail machine. For example sendmail doesn't like to send mail to the jail session if it sees the jail's IP is one of its own IPs. Sort of like, I'm already there why bother and it could cause mail looping under mis-configuration. This isn't a problem for the IBM type solution or vmware. Then with IBM the machine can disable a bad CPU and call home for a fix. None of the session are bothered (except performance) assuming you have more then one CPU working. Maybe we heard different bragging. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Neat kernel development environment.
Julian Elischer writes: | | I have just managed to get the following going: | | By writing a device driver that is two terminals back-to-back, | and configuring vmware to map one of the virtual ttys over the | 'null-modem' device, and then running a kernel configured with the console | on com1 and the gdb port on com2, (in the virtual machine in vmware) | I can on a single machine run a test system, allow it to run the vmware X | server, and at the same time have access to the console, AND be able to | single step it under xxdgb or DDB depending on the task. FYI, via the latest Etherboot port that was commited you can netboot a vmware machine. Could you post your null-modem device? ... it saves on serial ports. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [usb-bsd] USB to Serial Port , anyone working on it?
Nick Hibma writes: | The pointer to the source I can't give, because it has escaped me | whether I sorted out the licensing issue with Doug Ambrisko. I'd rather | would like to sort that out first. This shouldn't be an issue since it is the same license as the netgraph license from Whistle. I have to revisit this issue for Linux USB though. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/bin/ssh and SOCKS
James E. Pace writes: | | I rebuilt -current on Friday, and OpenSSH does not work through a | SOCKS firewall. | | In my make.conf, I have "USE_SOCKS= YES", which is used in the | ports/security/ssh port. As mentioned we have ssh in the base system so your are picking that up. Another alternative is to remove the setuid bits /usr/bin/ssh and then do a "runsocks ssh". LP_PRELOAD in FreeBSD does not work on setuid binaries. This is a security feature. Solaris let's you do a LD_PRELOAD on setuid binaries if the library is from /usr/lib. So on Solaris if the libsocks_sh.so was in /usr/lib then LD_PRELOAD of it would work on setuid binaries like ssh and it would just work without recompiling/linking. However, now that Dante is available and has BSD licensing we could include it in the base OS. Yes it is bloat, but then people could sysinstall behind a Socks firewall and things like ssh etc could be linked to it. There are things I like and don't like with Dante but it is a pretty good package and has a better license. I could do the work if deemed usefull. I don't want to maintain my own branch and we use the Nec implementation here so I don't want to be bouncing between them for no good reason. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New kernel no longer boots on one of my machines... ata, other problems
Matthew Dillon writes: | Well guys, I tried upgrading one of my older machines today to the | latest 4.0. It was running an older 4.0 kernel (Nov 29 1999). I ran into a similar problem when upgrading my server at home. It is an old 486 with an Intel Saturn chipset. I found the IDE drive via ad0 and failed the mount with error 6 or whatever. I then put the same drive in a machine with a P5 & Intel TX chipset. In this setup ad0 was found and it mounted the rootfs with no trouble. Since this is a machine that needs to be up I switched to the wd driver which worked like charm except for re-enabling it. So in my configuration it is not a MAKDEV/fstab stale issue (I rebuild all of that) and it works with a PCI driver but not with the Saturn ISA driver. My successful boot and probe is: wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 wdc0: unit 0 (wd0): , multi-block-16 wd0: 12897MB (26414640 sectors), 26205 cyls, 16 heads, 63 S/T, 512 B/S Now I recall in discussions about pcmcia stuff and the various patches flying around that there was a 32/16 bit access mode issue. Also I think while the pcmcia was in 32 bit mode hard disk access stopped working and maybe flash (since my external IDE hard drive work then it didn't then it did again). I think this correlated to when it was switched to 16 bit then it started working again. Anyways more work and lots of testing needs to be done. Even though I like the new ata stuff and use it on all machines (except for one) this is scary since a bunch of 4.0 users could get screwed with older good hardware. Tonight I will try to define ATA_16BIT_ONLY in my kernel and try to boot with ata. This may have to be set in GENERIC for installs to work ... or the ata driver learn how to figure this out automatically on the fly. BTW this almost hosed me. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BOOTP and IPFIREWALL
David Gilbert writes: | options BOOTP and options IPFIREWALL appear to be incompatible in | -CURRENT. I havn't tried -STABLE. While the kernel compiles fine, | the BOOTP code fails to send the discover packet and panic()'s. | | While it might not be immediately obvious that you'd want IPFIREWALL | in a BOOTP-loaded machine, there are good reasons for it... They are not really incompatible just your use is :-) Add options IPFIREWALL_DEFAULT_TO_ACCEPT#allow everything by default to your kernel. IPFW stuff is blocking any network traffic. So add this to your kernel and you firewall will default to open so BOOT etc will work (including nfs mounting of root & swap), then during the boot use the rc.firewall stuff to setup the firewall correct and then remove the default open rule. This is what I've done when playing with natd on a netbooted machine. (natd require ipfw & divert). If this fails it's news to me. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ATA driver as the default
D. Rock writes: | I just re-enabled the ATA driver again after reading the change log | of better error handling and automatic falldown DMA->PIO under specific | circumstances. | But a few days later, while making world (with the ata driver), the | system | crashed quite heavily. The file system was totally screwed up afterwards | (I found my /usr/local after some heavy searching: It magically | moved to /usr/obj/usr/src/tmp/usr/share/zoneinfo (!) and got tons of | fsck | messages). The file system had softupdates enabled. I don't know the | last kernel messages before the crash (was running X at that time). You might want to look at ata-disk.c and the timeout value around line 438: /* start timeout for this transfer */ if (panicstr) request->timeout_handle.callout = NULL; else request->timeout_handle = timeout((timeout_t*)ad_timeout, request, 5*hz); Originally it was 3s and recently increased to 5s. Personally I switched it to 30s after it trashed my filesystem when it was 3s. The issue was that 3s, is that it is to short to wait for my laptop's drive to spin back up. Sometimes I would get a corrupted read sometimes on a write it would trash things. I noticed in the old wd driver that it tried 10s first then a couple 3s timeouts. After making this change my system has been rock solid when the drive spins down. Note I haven't tried to tune this value since trashing a 14G filesystem is pain full. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Intel 810?
Mark Newton writes: | On Mon, Dec 06, 1999 at 07:52:20PM -0500, Garrett Wollman wrote: | | > < said: | > | > > As others have stated, Socket370 boards arent all 810/810c...my 4.0-Current | > | > The important issue to me is: will FreeBSD work on an 810 motherboard? | > The reason I care is because I need the form-factor (a 1U-high | > server); if I am to use some alternate motherboard, I'll need to be | > certain in advance that it will fit in a MicroATX opening. | | For what it's worth, we've been buying 1U servers pre-configured | (and pre-installed with FreeBSD) from Telenet Systems, http://www.tesys.com. | US$1199 for the entry-level model. To add to the 1U & 810 thread. - 810 does not support ECC memory from what I've read. - Several cases are available that use ATX or PICMG SBC boards. There are some others but not as interesting or standard. - ATX boards that can fit in a 1U case need a socket and not a slot. I think it is a risk to depend on generic ATX motherboard venders to make them in the future since the ATX spec does not meet the needs of 1U. 2U is fine, no issues. Boomrack has lots of solutions. Also you need to get everything on board since you only have one precious expansion slot (a right angle adapter). - NLX has same problem as ATX (besides I have a grip against NLX since you can't use off the shelf AGP cards in them ... there is a special spec for AGP/NLX) Try to buy one I dare you I eventually dug one up at 2X suggested retail). - PICMG SBC guys need to make thin boards for multi-slot machines so there are lots of Socket boards out their with "real" chipset (ie BX that support ECC memory). Also you can get onbard SCSI, VGA, Ethernet, USB etc. SBC's usually have watchdogs, DiskOnChip (in which you can easily stick a netboot rom) etc. - Lots of 1U cases a little "lame", meaning the SBC cases don't have mounts for all of the SBC boards options. You can only get so many things out a single slot. Mitac is the only company I've seen so far that has more then enough knock outs in their case (www.mitacinds.com). Also the Mitac case can fit a - CDROM - 3.5" hard drive - 3.5" floppy - 2.5" laptop drive All at the same time. I haven't found any other cases that can do that. Most require a laptop drive if you use a CDROM. Now most FreeBSD machines can get away with not having a CDROM so it isn't critical. - Expansion is usually one PCI/ISA slot. We use a D-Link 4 port ethernet card. This card is short enough to fit in the slot since it is not quite a full lenght slot with a CDROM. - Mitac does not use the Intel ethernet chip :-( We have a Mitac case in house and it is very nice. BTW the IBM 1U system is OEM'ed. There is also another company doing dual PII in 1U. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: - current diskless is it possible ?
Holm Tiffe writes:
| Is an NFS root supported in -current ?
| How is the syntax to set the rootdevice ?
| How about /boot/loader and friends <-> and etherboot ?
| (the port is outdated, it references etherboot-2.4.5.tar.gz
| and no one has this old file anymore, current is 2.4.10)
Yes it is possible, but you need to patch sys/i386/i386/autoconf.c. included
in this message. I've only tested in the case of netbooting so I could
broken normal booting.
Then use Etherboot. I also included it an uuencoded update to the
etherboot port for etherboot-2.4.10 which can boot a FreeBSD ELF kenel.
This all works as of -current (yesterday). Sorry it takes so long
for the port to get updated and the Linux guys keep working on Etherboot
(which BTW they has code to boot FreeBSD now and they test it). Then I
have to wait for someone to read the pr's that I send in. They when someone
finally looks at it. It is already obsolete. Same thing with my sdcc
port that needs updating.
I expect Mike will kill me for this, but it works and I don't have a PXE
rom in this machine. I prefer a netboot panic rather then panic'ing my
laptop when testing things.
Doug A.
Index: sys/i386/i386/autoconf.c
===
RCS file: /cvs/freebsd/src/sys/i386/i386/autoconf.c,v
retrieving revision 1.143
diff -c -r1.143 autoconf.c
*** autoconf.c 1999/11/02 19:38:27 1.143
--- autoconf.c 1999/11/24 18:39:47
***
*** 48,53
--- 48,54
#include "opt_bootp.h"
#include "opt_ffs.h"
#include "opt_cd9660.h"
+ #include "opt_nfs.h"
#include "opt_nfsroot.h"
#include "opt_bus.h"
#include "opt_rootdevname.h"
***
*** 213,224
--- 214,231
cold = 0;
}
+ #ifdef BOOTP
+ extern void bootpc_init();
+ #endif
/*
* Do legacy root filesystem discovery.
*/
void
cpu_rootconf()
{
+ #ifdef BOOTP
+ bootpc_init();
+ #endif
#if defined(NFS) && defined(NFS_ROOT)
#if !defined(BOOTP_NFSROOT)
if (nfs_diskless_valid)
***
*** 226,232
rootdevnames[0] = "nfs:";
#endif
#if defined(FFS) && defined(FFS_ROOT)
! setroot();
#endif
}
SYSINIT(cpu_rootconf, SI_SUB_ROOT_CONF, SI_ORDER_FIRST, cpu_rootconf, NULL)
--- 233,240
rootdevnames[0] = "nfs:";
#endif
#if defined(FFS) && defined(FFS_ROOT)
! if (!rootdevnames[0])
! setroot();
#endif
}
SYSINIT(cpu_rootconf, SI_SUB_ROOT_CONF, SI_ORDER_FIRST, cpu_rootconf, NULL)
begin 664 etherboot.tgz
M'XL(`!G].C@"`^U<:7/:3!+V5_0K>AW7QCG0?0`;4B$@>UD;<`%.]D.J>(48
M@0HA:768>%/Y[]LS`HP=9_VFUH%L/$]L(XE6S]'SS'2/6B'9C"3C*,JD@Y\&
MT&7+,N``0)55DWXBY-7GZ@0L63$-R]0T%4!1%=DX`.-@!\C3S$D`#IS%./'3
M>?0]N>6,D.#@MP/9V+_Y82#MU_ZR9FJF;%+[&YK,[;][^_?QX/'+4&39-/7_
M8G]-H_:7=471=(O:7].I_65N_Y^.6IR2Y(HDM77[W[E7:4W"/\(!Q^^/._PG
M<93Z691<[Y3_NG*'_[II:IS_NP!ENN0EA(S3B11'299*(>'Q!)$4VI$X4P(#&H%LAJ3=5JN@5*
MM5J5)*$E4:E4DMAQ[&3N[.9L/F5'G$[_Q_POS+OG^%\W#.;_JPJ/__=B_Y^Q
M"_`G[2];NJKIAD+M;VH:M_^^[/_8NP`_'O_KAJ;R]9_'_QQ[X?\C[P(\'/];
M=_AO6!:/_W^)^+\8%GPN>$K\?^Q=@(?Y;][EOZKJG/\[X?]B8F#HKWX;^AO:
M)O3G]'\R_,?A\.AE/,1_53:VXG^+QG\X&W#^[P*=E@''FT%0UD555&01NT2<
M_OL%U(%,7&-<'>MCLZ*ZQ-,UIVIZRMBJ&(8SUCQ%8`K&?IAG?I"65;$J*J(L
MJL:6#E4S9$>MJ%[%FQC:6)>KGJ%JQ+(\UQU799U/+[\"_]<;P0>[YK\JFS?[
M?[HF%_L_!N?_+O`,NF0)S/$'-PH"XF8^>@*+U6``+TIJ:*.;YX'/X`-)4BJ3
MD'_E?D(F->;"B0I^U7(R`FY"\*.XS![OF-"($S]@[@0*?9Q%BQK<02O*I]!8
MV0#>;'8CEC,_S0(BNM'BK?`,[SXZP6#E_:!5@_NBE?4@?GT%BF@4#HQ*D?4XKB#W5]?%K#F[>X0?^U^O71?CPO"^\OV>6O4LB_L;HLVUTD7
MM:,O%[W^<-!J][^N*DDO"T*W-[IH-,\:I]AC083C*?)P2(6>/\T3AXVJD+@D
M39WD6K@,C48A%%WW^5TL0M:ZJPW8`ZCI=[
M5AR`9U@"F>"?)5KX:C5,L193)Z4#&29.YJ`N(4Y(>5TS4A-*[@2VR[[56?`W
MVOU8HBAM;H'R+$JSNJ]5S'(>SL-H&997,30)O$+_./>#R9_23;DF").H[(%OIIK,FDEAM
MV'VK0@#'(R0X?KP@BN-K\!?.E(AX!_GL9Z`(@NB';I!/"+S!5HF4:^)B_I8O
MU;_M^K]^I/OX9?Q`_J=N*NSYGZ&:_/G/?NS//LN.L[OXS]3UU?Z/;"F6RO9_
M9+[_NQ.\?/D2UDX3.B#^M'22^-!S,U!5D*LUQ:II10Z(4"Z7-Z)WI2HU=27U
M\C;H.5CZ:ZL*[)0JP=.*#'A4%@":)^>-T\&K>JGG..%=\]I+6&0.>X<%CCD8$SP)\!EVM3E^1C2")8$9LX5+LK$"6!!%E%R
M31?IA`A[X?]X9_S'>=_8\%]C^S]\_W>7_&\RO_8^]JMR3=YB?R'XK0Q&5=_E
M?D5]7:D4W+]%Y$YOV()RJ]W!>&'4L;N7!:V>@1TZXR+PA%6H!W1\%AXJI'E,
M*2[\!26WM#5ZE\,1TX4Z[?.3XGBM\@1UQ>CLQID?3ID7/"&>DP<98'R0^0L2
MY1D3W-8X.!N][_6&=14U-KH##().&I?GPSH][MK#C[W^&>N4HH'?SF;_5<(O3_M^RN`9K[6U1OOCY[JZ_F23DOKC8;#S5@49X>WO@A]EUYZA9>\$.[#_SWD'^,?MKVD*
MS__=D_T?_QW@'\O_I>N_KBH\_W'E!=[)]$MPF8
MI`FJ4M/U]38!SRG^5?E?#(9'+N/A]1_Y;UJ:H2(L]OZGI?/U?R?HDHP]?%@_
MB7#$*,\D^_P$BJ0T'@8\)?ZS2?[1RW@P_T-E_)?I__YAZ$7^C\;YOQ,,9SY-
M_)T06#HIT"<`?N@$U^`ET>)F4@@G-!4A9$F#YW2/';PHF*LZL3/V\13]2A&@G4'F9?'SE.DKYAD0J"`=B"DJ
M*82<((U@AM5R8$'"_$;-M2@((JW@7X&FJ19/3E$L(2S1,0,_!);T<3.ZBS12
MU&M/_`P.BR?9AX)/VX1>S\1/B$MC7O98=A&A)@^;EB=884'H1AE!.>PIOZ@,
M2\YPHR3)8Y;8ZJ=ICCU(NZ@--/LSCN(\<-A=A+7*#[U(2+,D=ZE2E&*9JED$
M013-`6N`M:+%BL(^^<_#^`\X[=E0`'@```<'
`
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: buildworld across signal changes not quite right
Peter Jeremy writes: | Thanks to Marcel's latest Makefile.inc1 changes (1.92), a -current | buildworld running on an older -current system now progresses much | further - in fact it now completes :-). | | There are, however still a few problems - as far as I can tell, these | are all related to the wrong version of perl being called whilst perl | is being built in the ">>> Building everything.." section. | | I'm not sure how to fix this problem. Unlike our other build tools, | perl is not designed to be able to be cross-built: It builds bits | of itself and assumes they can be safely executed to build other bits. Yes this is very tricky. I run into a lesser issue when switching from threaded perl to unthread perl. This is currently broken since it doesn't link with the just built libs. This is further complicated in that other things sometimes need to find out how perl was built by asking perl. An example is vi with perl support which is also broken under threads. I can't see an obvious around this except to build a "build tools" version for use during the build and then a final version. An issue with this would be how to generate the config.h for the build platform since we currently have those pre-made for our target platforms. This doesn't address the issue of perl needing to report how it was built. I have sent in fixes for the 2 threaded perl issues. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: wi driver
Blaz Zupan writes: | I'm trying to make the wi (WaveLan) driver work in -current. It appears | that some changes to the pccard code have broken it (or that I can't find | out how to configure it correctly, although I have done it under 3.3 with | success). I have this in my config file: It needs to be converted to newbus. I've done this to Bill Paul's Aironet driver for -current (however, his driver doesn't work with an access point correctly but the driver for Linux does so I have some work to do). You can use the /sys/dev/ed driver as a model. I don't have a card like that to test with. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm0 is not found: "unknown0:"
Phil Regnauld writes: | I was running a kernel from end of august, and everything worked | fine (IBM PC 300 PL, PII-350, 128 MB RAM, built-in audio): | | Oct 5 13:28:29 aylee /kernel: pcm1 (CS423x/Yamaha/AD1816 sn 0x) at |0x530-0x537 irq 5 drq 1 flags 0x13 on isa | | Since make world last week: | | unknown0: at port 0x534-0x537,0x388-0x38b,0x220-0x22f irq 5 drq 1,0 on isa0 | unknown1: on isa0 | unknown2: at port 0x120-0x127 on isa0 Apply this patch in /sys/dev/pcm/isa Don't know why it is reporting 0x0001630e instead of 0x630e I'm using pcm with pnp. Doug A. Index: mss.c === RCS file: /cvs/freebsd/src/sys/dev/pcm/isa/mss.c,v retrieving revision 1.31 diff -c -r1.31 mss.c *** mss.c 1999/10/12 21:35:45 1.31 --- mss.c 1999/11/15 19:50:09 *** *** 1268,1274 else if (id == 0x3200630e) s = "CS4232"; else s = "Unknown CS"; break; ! case 0x2100a865: /* YMH0021 */ if (id == 0x2000a865) s = "Yamaha SA2"; else if (id == 0x3000a865) s = "Yamaha SA3"; --- 1268,1277 else if (id == 0x3200630e) s = "CS4232"; else s = "Unknown CS"; break; ! case 0x0001630e: /* CSC0100 */ ! if (id == 0x2500630e) s = "CS4235"; ! else s = "Unknown CS"; ! break; case 0x2100a865: /* YMH0021 */ if (id == 0x2000a865) s = "Yamaha SA2"; else if (id == 0x3000a865) s = "Yamaha SA3"; To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: No buffer space available errors
Bill Marquette writes: | For the last week and a half or so I've been trying to track this down | assuming it was a configuration error on my part or a problem with my | ISP's DHCP configuration. After switching from a DEC 20141 chipset card | to a 3com 3c905, I found I was still having problems although the error | message had changed. I'm now back to the DEC card cause I found more | results in the mailing lists on the errors I was seeing. | | At first it appeared to be dhclient having issues, but I've finally found | occurances of other programs showing symptoms prior to dhclient log | entries. Also, until today I couldn't replicate the problem while sitting | at the console, it would only show itself after I'd been away for a few | minutes (I swear it has a mind of it's own) usually, when I was going to | be away for more than 10-15 minutes. Today I managed to force the machine | to have problems by doing multiple simultaneous downloads and uploads, I | was running about 100K/sec through the NIC. On one out of 8 machines, I ran into this problem. My network is running at 100BaseTX. I noticed that ifconfig showed OACTIVE flag set and I was running in autosense mode. So I setup the media to 100BaseTX and now it works okay. My guess is the autosense gets confused sometimes. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
Kevin S. Brackett writes: | Oh, well then, :) I'm glad I said something before I actually bought one | (I saw the atapi RW drives were rather cheap now (~US$125)) I think that most IDE CD-R/CD-RW will just work using Soren's ata driver in current. I'm doing that on my laptop right now with a hacked pccard and hacked ata driver. Also I have an external IDE hard disk as well. I do have a problem with buffer underflows when do a mkisofs to a 4X write over PCMCIA. 2X works fine. BTW I'm using a Sony drive. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
Kevin S. Brackett writes: | Oh, well then, :) I'm glad I said something before I actually bought one | (I saw the atapi RW drives were rather cheap now (~US$125)) I think that most IDE CD-R/CD-RW will just work using Soren's ata driver in current. I'm doing that on my laptop right now with a hacked pccard and hacked ata driver. Also I have an external IDE hard disk as well. I do have a problem with buffer underflows when do a mkisofs to a 4X write over PCMCIA. 2X works fine. BTW I'm using a Sony drive. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS diskless on -current
Mark Newton writes:
| I tried to upgrade my diskless router this afternoon to -current as
| cvsupped last night.
|
| I can't make it boot, though.
|
| It now panics with "Can't mount root" when I boot it. And yes, I have
| updated the kernel config for new-bus.
|
| I noticed the BOOTP stuff in LINT, but that's been there for a while and
| I've never needed to use it before. I turned it on anyway just to see
| what happens, but tcpdump doesn't show it sending any bootp requests.
I have a fix for you based on the MFS mount root problem! Note it is
a best guess and works for me. It seems rootdev needs to be defined
or it ignores trying to mount it. I ran into this a couple of days
ago.
Doug A.
Index: bootp_subr.c
===
RCS file: /cvs/freebsd/src/sys/nfs/bootp_subr.c,v
retrieving revision 1.19
diff -c -r1.19 bootp_subr.c
*** bootp_subr.c1999/01/27 23:45:39 1.19
--- bootp_subr.c1999/05/29 16:52:14
***
*** 1043,1048
--- 1043,1049
panic("nfs_boot: lookup swap, error=%d", error);
}
nfs_diskless_valid = 3;
+ rootdev = makedev(255,0);
}
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: deadlock in 3.1-RELEASE
Andrew Heybey writes: | When the deadlock does occur, "ps" (in ddb) says that there are many | processes in vmwait. The pagedaemon is in an inode wait. The stack | trace is in default_halt() (which I assume just means that there are | no runnable processes). The system is not short of memory (unless | "short of memory" means that it is attempting to use it all as a disk | cache). | | A search of cvs-commiters for "vmwait deadlock" did not reveal (to my | ignorant eye, anyway) any fixes to -current that would apply to this | problem. I have an environment that triggered this in less then 1/2 hour. Julian with the help of his friends (ie Matt & Alan) have brought in some changes from -current that got rid of my problem. Getting the latest RELENG_3 stuff should fix it. My processes got stuck on vmwait. Doug A. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: netboot status ? (diskless related)
Luigi Rizzo writes: | given that now 3.1/4.0 seem to have better diskless support, | i am in the need of building the boot images for the diskless | workstation. Netboot does not support elf kernels, so i think i have | the following alternatives: | * use netboot with an aout kernel | * build a bootable floppy with an ELF kernel (btw what is the magic |sequence to put the appropriate stuff on the disk, something along |the lines of * or use my etherboot port that is pr: [1999/01/13] ports/9480 portsELF kernel netboot Note it needs two patches that have be found since the original PR. It supports a.out, ELF, mknbi images (ie DOS and some other stuff). Doug A. One of atleast a couple people netbooting ELF kernels, starting to think people don't care about netbooting anymore. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
