From owner-freebsd-hackers Sun Sep 1 8:52:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C55637B405 for ; Sun, 1 Sep 2002 08:52:34 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63B7043E65 for ; Sun, 1 Sep 2002 08:52:33 -0700 (PDT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.pr.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with ESMTP id g81FqDOo038926; Sun, 1 Sep 2002 11:52:13 -0400 (EDT) (envelope-from rwatson@FreeBSD.org) Date: Sun, 1 Sep 2002 11:52:12 -0400 (EDT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Patrick Thomas Cc: freebsd-hackers@FreeBSD.org Subject: Re: setting quotas _inside_ a jail for users _inside_ a jail In-Reply-To: <20020830003917.O58763-100000@utility.clubscholarship.com> Message-ID: <20020901114733.K46180-100000@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 30 Aug 2002, Patrick Thomas wrote: > I realize the difficulties in trying to use quotas on the _host_ > system to limit the size of jails on the host system - userid mapping, > etc. This is not what I am asking. > > I wonder, is it possible for the root user of a jail to set quotas > _inside_ her jail for users _inside_ her jail ? Can anyone simply > confirm or deny that this is possible ? > > Simply following normal protocol does not work, because if you place > filesystem entries into /etc/fstab inside the jail, the jail will no > longer start, as it does not have permission to mount or otherwise > manipulate those filesystems. Other than the access control checks in the quota code being influenced by the jail, there really is no relationship between jails and quotas. Jails are solely a property of processes and other credential-bearing kernel objects. Persistent and transient quota information is stored relative to uids and gids, and quotas are enforced based on those elements of the process credential, and are not impacted by the jail field. This means that if a file system is shared by two jails, and a particular uid is in use in both jails, both sets of processes will be impacted by the same quota. Privileged users can perform quota management calls on any file system they can name via a visible file object. If quota management calls were permitted from jail, they could likewise be performed on any file system visible in the jail. If only appropriate file systems are visible from the jail, you could add PRISON_ROOT to the flags field of the relevant suser call. If you expose file systems to the jail that you don't want the root user in the jail to set quotas on, you may be out of luck. I take it from your description that you're interested in imposing quotas on the users in the jail, not quotas on the jail itself? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 1 11:23:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A603A37B400 for ; Sun, 1 Sep 2002 11:23:14 -0700 (PDT) Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20CBB43E6A for ; Sun, 1 Sep 2002 11:23:14 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from wonky.feral.com (wonky.feral.com [192.67.166.7]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g81INDv09025 for ; Sun, 1 Sep 2002 11:23:13 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sun, 1 Sep 2002 11:21:38 -0700 (PDT) From: Matthew Jacob Reply-To: To: Subject: anyone seen this 5.0 panic on reboot? Message-ID: <20020901112044.Y16984-100000@wonky.feral.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8d fault code = supervisor read, page not present instruction pointer = 0x8:0xc02c7d24 stack pointer = 0x10:0xd26579ac frame pointer = 0x10:0xd26579dc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 354 (halt) kernel: type 12 trap, code=0 Stopped at 0xc02c7d24 is 0xc02c7d24 : cmpl $0x27,0x8c(%esi) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 1 16: 3:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFF2C37B408; Sun, 1 Sep 2002 16:03:19 -0700 (PDT) Received: from relay.kiev.sovam.com (relay.kiev.sovam.com [212.109.32.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BC0F43E65; Sun, 1 Sep 2002 16:03:17 -0700 (PDT) (envelope-from evrostar@mark.com.cn) Received: from [212.109.32.38] (helo=212.26.128.2) by relay.kiev.sovam.com with smtp (Exim 3.34 #1) id 17ldfe-000DIm-00; Mon, 02 Sep 2002 01:58:27 +0300 From: info To: "" <> Subject: Работа в Чешской Республике ! Organization: info Reply-To: evrostar@mark.com.cn X-Mailer: The Bat! (v1.52f) Business Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Date: Sun, 2 Sep 2012 01:58:07 -0000 Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Попробуйте найти работу в Чешской Республике! Если у Вас нет подтвержденного высшего образования технического, или экономического направления. Если Вы абсолютно довольны Вашим работодателем и условиями оплаты. Если вас устраивает экономическая и криминальная ситуация в Вашем городе/стране. То это обращение не для Вас, и Вы можете его спокойно удалить. В результате оттока инженерских кадров на запад, в Чехии образовался повышенный спрос на квалицированных специалистов с высшим образованием. * У Вас высшее образование технического, или экономического направления? * Вы не можете найти работу? * Вас не устраивает условия оплаты, или среда обитания? Попробуйте найти работу в Чешской Республике! Условия оплаты: - начальная зарплата - 12.000,- - 15.000,- крон (400,- - 500,- Евро) - при успешном выполнении производственных задач и подтверждения квалификации зарплата - 40.000,- - 50.000,- крон (1.350,- - 1.600,- Евро). Для справки - прожиточный минимум в Чехии составляет 4.500,- Крон чешских. При этом не забывайте, что с вступлением Чехии в Европейский Союз, зарплата будет расти, а курс Евро к Кроне понижаться! Чешские заводы и исследовательские организации ждут Вас! Международный Информационный центр (INFOCENTR) предлагает Вашему вниманию эксклюзивную программу по адаптации и подбору рабочего места в Чешской Республике. -------------------------------------------- Продолжительность программы 4 - 5 месяцев (в т.ч. 3-х месячные курсы языка + 1 мес. стажирвока) В стоимость программы входит: 1/ Подбор рабочего места. 2/ Курсы чешского языка. 3/ Стажировка на выбранном предприятии. 4/ Оплаченное проживание на все время нахождения в Чехии. 5/ 3-х месячное приглашение в Чехию. 6/ Бесплатное сопровождение квалифицированным личным консультантом! Вы всегда сможете обартиться к нашим представителям в Чехии для разъяснения основных юридических, хозяйственных и бытовых вопросов. Стоимость программы: - с проживанием (в т.ч. завтрак) - 2.300,- дол. США - с проживанием (без завтрака) - 1.700,- дол. США - без проживания - 1.150,- дол. США Примечания. ------------ 1/ Прием анкет и анализ возможных вариантов по трудоустройству производится БЕСПЛАТНО. 2/ Обязательств по ответам на все присланные анкеты, или на иные обращения, мы НЕ НЕСЕМ! 3/ Ответы на присланные анкеты, с указанием контактов на наших представителей, будут посланы в порядке их обработки и только на контактный е-мейл. 4/ Оплата за всю программу может быть проведена на основании официального счета-фактуры за курсы чешского языка в аккредитованном чешском учебном заведении, или через систему Анелик. Оплата услуг за перевод производится отправителем. 5/ После получения оплаты с Вами будет согласована программа стажировки, основой которой будет учебный план курсов чешского языка. После утверждения сроков Вашего приезда, Вам будет прислано официальное приглашение на учебу для получения многоразовой 3-х месячной визы в чешском Консульстве. ОПЛАТА ВИЗОВОГО СБОРА В СТОИМОСТЬ ОБУЧЕНИЯ НЕ ВХОДИТ! 6/ В случае Вашей невозможности приехать в Чехию по независящим от нас причинам, после согласования даты начала обучения, Инфоцентр не нет обязательств по полному возврату полученных денег! Если Вас заинтересовало наше предложение, пожалуйста, ответьте на анкету и отправьте на мейл: mailto:inzenyry@infocentr.cz (только для анкет!): 1/ Ф.И.О. 2/ Дата рождения 3/ Специальность по диплому 4/ Название, адрес ВУЗа/ов 5/ Дата окончания ВУЗа/ов 6/ Стаж работы по специальности, подтвержденный в трудовой книжке. 7/ Настоящее место работы, должность 8/ Знание иностранных языков 9/ Семейное положение 10/ Наличие детей, их количество 11/ Прочее (по Вашему усмотрению) 12/ Контактный е-мейл. С уважением, Международный Информационно центр в Чехии (INFOCENTR) mailto:inzenyry@infocentr.cz (только для анкет!) Tel/fax: +420 38 610 6147 Сергей Викторович evrostar@mark.com.cn ************************************************************************ Примечание. МАССОВЫЕ РАССЫЛКИ НЕ ПРОТИВОРЕЧАТ ЗАКОНОДАТЕЛЬСТВУ РФ и Украины. Дополнительную информацию о правовых аспектах e-mail рассылок Вы можете получить на сайте "Общественного Совета по Информационному Обмену в Сети" http://www.osios.org/ Информация по вопросу рассылки обращатся по адресу mailto:listmail@home.ro ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 1 17: 5:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82D9737B400 for ; Sun, 1 Sep 2002 17:05:51 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA4BE43E75 for ; Sun, 1 Sep 2002 17:05:50 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.5/8.12.2) with ESMTP id g8205HcV038825; Sun, 1 Sep 2002 17:05:17 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.5/8.12.5/Submit) id g8205GUv038824; Sun, 1 Sep 2002 17:05:16 -0700 (PDT) Date: Sun, 1 Sep 2002 17:05:16 -0700 From: "David O'Brien" To: Terry Lambert Cc: mark tinguely , akoskine@cc.helsinki.fi, freebsd-hackers@FreeBSD.ORG Subject: Re: More dynamic KVA_SPACE Message-ID: <20020902000516.GA38501@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <200208301437.g7UEbxL36566@web.cs.ndsu.nodak.edu> <3D6F8941.111A0C39@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D6F8941.111A0C39@mindspring.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Aug 30, 2002 at 08:03:29AM -0700, Terry Lambert wrote: > For all we know, AMD has gotten out of the new Silicon business all > together, and will simply be shipping upgraded simulators of things > which would be cool if they were ever taped out, plactic'ed, and > slotted in a ZIF in non-existant motherboards, but which, in reality, > never make it to glass. WTF are you talking about?!?!?!? I have 2 AMD x86-64 1P Clawhammers undermydesk. I also have a 2P x86-64 Sledgehammer nearby. The Clawhammer desktop systems will ship 1Q03. 2P systems will come out 1H03. > > I just wish AMD added an 8K page size so the Page Table Maps did not > > eat so much memory. > > More proof that hardware people don't ask software people how they > expect to use the hardware after it's built. Feh. The x86-64 'swapgs' instruction was added at the direct request of the SuSE Linux folks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 1 17:26: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF97E37B400; Sun, 1 Sep 2002 17:26:05 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 865D843E72; Sun, 1 Sep 2002 17:26:05 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.5/8.12.2) with ESMTP id g820Q5cV039056; Sun, 1 Sep 2002 17:26:05 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.5/8.12.5/Submit) id g820Q5L2039055; Sun, 1 Sep 2002 17:26:05 -0700 (PDT) Date: Sun, 1 Sep 2002 17:26:05 -0700 From: "David O'Brien" To: Gregory Neil Shapiro Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: why does this sendmail connection take so long? Message-ID: <20020902002605.GB38501@dragon.nuxi.com> Reply-To: freebsd-hackers@FreeBSD.ORG References: <3D6E243B.1515.8EB744E7@localhost> <3D6E2D31.29065.8EDA44C7@localhost> <15726.26491.969569.176848@horsey.gshapiro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15726.26491.969569.176848@horsey.gshapiro.net> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Aug 29, 2002 at 11:27:07AM -0700, Gregory Neil Shapiro wrote: > That explains it. You have a record pointing localhost.example.org at ::1 Unfortunately this is our default configuration: # $FreeBSD: src/etc/hosts,v 1.15 2001/12/11 22:36:10 rwatson Exp $ ..snip.. ::1 localhost localhost.my.domain 127.0.0.1 localhost localhost.my.domain This has caused me trouble before and I've been >< close to reversing the IPv6 and IPv4 lines... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 1 18:18: 0 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 218E637B400; Sun, 1 Sep 2002 18:17:56 -0700 (PDT) Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3A0B43E77; Sun, 1 Sep 2002 18:17:55 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g821Ejg85150; Sun, 1 Sep 2002 18:14:45 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Sun, 1 Sep 2002 18:14:45 -0700 (PDT) From: Patrick Thomas To: Robert Watson Cc: Subject: Re: setting quotas _inside_ a jail for users _inside_ a jail In-Reply-To: <20020901114733.K46180-100000@fledge.watson.org> Message-ID: <20020901181045.S58763-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG No, sorry I think that I was misunderstood - here is my situation: - I have a host machine with no users - just root. - on that host machine I have a vn-backed FS 500 megs in size - on that vn-backed FS, I run a jail - and no other jails share that vn-backed FS (although other jails may share the underlying actual disk FS that the vn is on...) Now, I die in a car accident and nobody ever logs into the host system again or touches anything on the _host system_. Can the root user of the _jail running on the host system_ set up quotas for her users ? Let's assume the root user and all her other users don't even know it is a jail - as far as they are concerned, it's just their freebsd machine. So the question is, can this root user set up quotas ? And if so, some hints on exactly what needs to go into /etc/fstab _inside their jail_, since specifying anything in there seems to have the side effects of: a) not working as expected b) causing the jail not to be startable. thanks, PT On Sun, 1 Sep 2002, Robert Watson wrote: > > On Fri, 30 Aug 2002, Patrick Thomas wrote: > > > I realize the difficulties in trying to use quotas on the _host_ > > system to limit the size of jails on the host system - userid mapping, > > etc. This is not what I am asking. > > > > I wonder, is it possible for the root user of a jail to set quotas > > _inside_ her jail for users _inside_ her jail ? Can anyone simply > > confirm or deny that this is possible ? > > > > Simply following normal protocol does not work, because if you place > > filesystem entries into /etc/fstab inside the jail, the jail will no > > longer start, as it does not have permission to mount or otherwise > > manipulate those filesystems. > > Other than the access control checks in the quota code being influenced by > the jail, there really is no relationship between jails and quotas. > Jails are solely a property of processes and other credential-bearing > kernel objects. Persistent and transient quota information is stored > relative to uids and gids, and quotas are enforced based on those elements > of the process credential, and are not impacted by the jail field. This > means that if a file system is shared by two jails, and a particular uid > is in use in both jails, both sets of processes will be impacted by the > same quota. > > Privileged users can perform quota management calls on any file system > they can name via a visible file object. If quota management calls were > permitted from jail, they could likewise be performed on any file system > visible in the jail. If only appropriate file systems are visible from > the jail, you could add PRISON_ROOT to the flags field of the relevant > suser call. If you expose file systems to the jail that you don't want > the root user in the jail to set quotas on, you may be out of luck. I > take it from your description that you're interested in imposing quotas on > the users in the jail, not quotas on the jail itself? > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > robert@fledge.watson.org Network Associates Laboratories > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 1 21:37: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97C7137B400 for ; Sun, 1 Sep 2002 21:37:05 -0700 (PDT) Received: from shell.dragondata.com (einsteinium.4ph.com [66.197.0.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id C543D43E42 for ; Sun, 1 Sep 2002 21:37:04 -0700 (PDT) (envelope-from toasty@shell.dragondata.com) Received: (from root@localhost) by shell.dragondata.com (8.11.4/8.11.3) id g824b4W97627 for hackers@freebsd.org; Sun, 1 Sep 2002 23:37:04 -0500 (CDT) (envelope-from toasty) From: Kevin Day Received: (from toasty@localhost) by shell.dragondata.com (8.11.4/8.11.3av) id g824b2Z97618 for hackers@freebsd.org; Sun, 1 Sep 2002 23:37:02 -0500 (CDT) (envelope-from toasty) Message-Id: <200209020437.g824b2Z97618@shell.dragondata.com> Subject: Free EISA/PCI/SMP motherboard To: hackers@freebsd.org Date: Sun, 1 Sep 2002 23:37:02 -0500 (CDT) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by dragondata.com virus scanner Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I can't count the number of times someone's dug up on a mailing list that I posted on ages ago when I was using an old Pentium SMP motherboard with both EISA and PCI on it, asking me to test some new bus and/or SMP code. I'm cleaning up my house and ready to start throwing stuff out. If anyone wants this motherboard, please let me know. It's got dual Pentium 60's on it, 4 EISA and 4 PCI slots, and the Neptune chipset. Yes, I realize how horrible this monster is, but at least a dozen times I've had people ask me to try code on it, so I'm thinking this might be valuable to SOMEONE before I trash it. Contact me off list if you want it, no charge. I'll even pay shipping and include a pile of SIMMS if I can find them. -- Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 1 21:52:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1099337B401; Sun, 1 Sep 2002 21:52:50 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9F6743E65; Sun, 1 Sep 2002 21:52:49 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0170.cvx21-bradley.dialup.earthlink.net ([209.179.192.170] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ljCc-0005GK-00; Sun, 01 Sep 2002 21:52:42 -0700 Message-ID: <3D72EE54.90EA7977@mindspring.com> Date: Sun, 01 Sep 2002 21:51:32 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Brandon D. Valentine" Cc: David O'Brien , mark tinguely , akoskine@cc.helsinki.fi, freebsd-hackers@FreeBSD.ORG Subject: Re: More dynamic KVA_SPACE References: <20020901192245.E1008-100000@taran> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "Brandon D. Valentine" wrote: [ ... AMD ... ] > In all seriousness I'm not sure where he got the idea that "these things > were supposed to be out a while ago" but I don't recall any claims from > AMD to confirm that. If anything AMD's development cycle for these > things makes Intel's development cycle for IA64 downright embarassing. > The x86-64 silicon will be on the market on schedule and according to > the benchmarks I've seen will be doubling the IPC of AMD's already > impressive x86-32 hardware. Plus, I hear they run cool, which would be > a pleasant change from the current Athlons and might actually make AMD > processors a viable option in dense environments. At one point in time, I was working on a product that really, really cared about more than 4G of linearlly addressable memory (i.e. PAE need not apply, since only a moron would implement the particular product that way, given the overall requirements). The original claims for the tape-out on the x86-64 from AMD so that this could happen were September 2001, with sample units 1Q2002. The AMD schedule slipped. I realize that schedule slippage is practically the norm, these days, so nobody questions it any more, but that doesn't make it any less annoying for people who try to do what they say when they say. You'll notice that I *clearly* identified the posting as a rant. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 1 21:59:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1013C37B400; Sun, 1 Sep 2002 21:59:37 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9BE743E65; Sun, 1 Sep 2002 21:59:36 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0170.cvx21-bradley.dialup.earthlink.net ([209.179.192.170] helo=mindspring.com) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17ljJH-00034O-00; Sun, 01 Sep 2002 21:59:35 -0700 Message-ID: <3D72EFF1.1EABD92F@mindspring.com> Date: Sun, 01 Sep 2002 21:58:25 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrick Thomas Cc: Robert Watson , freebsd-hackers@FreeBSD.org Subject: Re: setting quotas _inside_ a jail for users _inside_ a jail References: <20020901181045.S58763-100000@utility.clubscholarship.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Patrick Thomas wrote: > No, sorry I think that I was misunderstood - here is my situation: > > - I have a host machine with no users - just root. > - on that host machine I have a vn-backed FS 500 megs in size > - on that vn-backed FS, I run a jail - and no other jails share that > vn-backed FS (although other jails may share the underlying actual disk FS > that the vn is on...) This is the magic part: quotas are per-UID, per-FS, but Robert is correct about their relationship to jails. What you failed to communicate to Robert is that you have also arbitrarily defined FS's to be per-jail, which, in the limit, will (effectively) make quota per-UID, per-jail. Most people don't use vn-backed FSs for jails. > Now, I die in a car accident and nobody ever logs into the host system > again or touches anything on the _host system_. > > Can the root user of the _jail running on the host system_ set up quotas > for her users ? Let's assume the root user and all her other users don't > even know it is a jail - as far as they are concerned, it's just their > freebsd machine. The answer is "yes". The method of doing this was already posted in this thread. You have to do evil things to the fstab within the jail itself, and outside the jail, but if you wave the correct dead chicken, it works. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Sep 1 22:58:56 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5186E37B400; Sun, 1 Sep 2002 22:58:53 -0700 (PDT) Received: from globalrelay.com (h216-18-71-77.gtcust.grouptelecom.net [216.18.71.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EF9443E4A; Sun, 1 Sep 2002 22:58:52 -0700 (PDT) (envelope-from lists@globalrelay.net) Received: from [24.81.109.7] (HELO beair) by globalrelay.com (CommuniGate Pro SMTP 3.5.9) with SMTP id 1401336; Sun, 01 Sep 2002 22:59:00 -0700 Message-ID: <02ec01c25246$2c207c30$076d5118@beair> From: "Eric Parusel" To: , "Gregory Neil Shapiro" References: <3D6E243B.1515.8EB744E7@localhost> <3D6E2D31.29065.8EDA44C7@localhost> <15726.26491.969569.176848@horsey.gshapiro.net> <20020902002605.GB38501@dragon.nuxi.com> Subject: Re: why does this sendmail connection take so long? Date: Sun, 1 Sep 2002 22:59:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > On Thu, Aug 29, 2002 at 11:27:07AM -0700, Gregory Neil Shapiro wrote: > > That explains it. You have a record pointing localhost.example.org at ::1 > > Unfortunately this is our default configuration: > > # $FreeBSD: src/etc/hosts,v 1.15 2001/12/11 22:36:10 rwatson Exp $ > ..snip.. > ::1 localhost localhost.my.domain > 127.0.0.1 localhost localhost.my.domain > > This has caused me trouble before and I've been >< close to reversing the > IPv6 and IPv4 lines... I swapped them since I have log_in_vain turned on, and I didn't like the extra alerts I was getting. Works great for me... Now just if I could get Sendmail to not do those dang identd checks all the time... The less "false alarms" that log_in_vain reports, the more safe and cozy I feel :) Eric To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 3:15:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDC3237B401 for ; Mon, 2 Sep 2002 03:15:49 -0700 (PDT) Received: from smtp01.01.246.ne.jp (smtp01.01.246.ne.jp [210.253.192.39]) by mx1.FreeBSD.org (Postfix) with SMTP id B81D543E42 for ; Mon, 2 Sep 2002 03:15:48 -0700 (PDT) (envelope-from jir@01.246.ne.jp) Received: (qmail 265 invoked by alias); 2 Sep 2002 19:15:41 +0900 Received: (qmail 196 invoked from network); 2 Sep 2002 19:15:39 +0900 Received: from unknown (HELO mebius2) (210.253.214.225) by tp01001 with SMTP; 2 Sep 2002 19:15:39 +0900 Message-ID: <01d001c25268$aab76fa0$0201a8c0@mebius2> From: "jir" To: "=?iso-2022-jp?B?GyRCNURPQBsoQg==?=" , , Cc: , , "freebsd-hackers@FreeBSD.O" References: <20020902092912.94612.qmail@web306.mail.yahoo.co.jp> Subject: =?iso-2022-jp?B?UmU6IFtwZWFjZTo1OTk4XSBSZTogGyRCOFtNUUIlP0pALzp2JHIbKEI=?= =?iso-2022-jp?B?GyRCJF4kOjxoJGskWSQtGyhC?= Date: Mon, 2 Sep 2002 19:08:18 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG =1B$B$&!A$5$s$X=1B(B =1B$B$A$g$C$H4E$$!A=1B(B =1B$B$8!!$G$9!#=1B(B : = =1B$B!V$8!W$5$s$O!"%1%$%s%:$NA0Ds>r7o$,K~$?$5$l$F$$$k$h$&$J0U8+$G$9$M!#=1B= (B =1B$B9q2H$O7P:Q3X$NNN0h$G$O$"$j$^$;$s!"7P:Q3X$r4^$`!"@/<#3X!"K!3X!"9q:]fIW$H$ODj5A$7$F$J$$$+$b!#=1B(B =1B$B$d$O$j9qL1@$O@!J$O$H$]$C$]!K$OB>?M!JGO$KJ9$-F~$l=1B(B =1B$B%+%i%9$bM6$$!"A10-J;$;F]$`@/:v46O@$r9M$($M$P$J$i$J$$$G$7$g$&!#=1B(B =1B$B$7$+$7$3$3$^$G=3DnL1$OI,MW$+$H$f$&$H!"%i%C%Q$N65M\$r$=3D$3$^$G$7$J$$= $H=1B(B =1B$BBLL\$h!"$H$f$&$3$H$G$9!"%^%9%3%_5,@)$OI,MW$J$N$G$9!#=1B(B =1B$BAjB3@GF($l!"3$30;q6b1#$7$K9qL1GXHV9f$OI,MW$J$N$G$9!"=1B(B =1B$B>pJs$O4m81$rH<$&$,0BA4$bJ]>c$9$k$N$G$9!#=1B(B =1B$B8xL@E^$N6b8"G[I[$b$$$$$G$7$g$&!#=1B(B =1B$B%P%i%s%93NJ]$K$O!"$;$$$<$$%G%U%lBP:v$K$O>/$J$$NL$G$O!"$O$H$NJ5$G$9!#= =1B(B =1B$B$G$;$C$+$/#G#D#P%P%i%s%9$G@G<}30$N;q6b$,9q2H$,F@$?$H$-$K$3$=3D=1B(B =1B$B$=3D$l$G@$3&$X$N8x6&Ej;q!"%(%M%k%.!pJs!";q8;%O%$%&%(!<$N0l4D$N9qFbLV$@$C$?$N$G$9!"=1B(B =1B$BGOrE*@UG$$,$"$j$^$9!#=1B(B =1B$B$"$/$^$G$b8D?M<{MW$,B-$j$J$$860x$O=3DjF@$,6!5kNO$h$j$*$H$j=1B(B =1B$B7P:Q:bL3%P%i%s%9$NGOAw@)8f=1B(B =1B$B!d=3D8CD$O$/$A2=3D?d?J$GHK1I$r=1B(B =1B$B!d$P$+$P$+F|6d;fJ>0u:~!"GOe$,$l$P$$$$$N$G$9!"=1B(B =1B$B2?$,6b;}$AF|K\$@!##3!s$,0.$k#7#0!s$N;q6b=1B(B =1B$B#7#0!s$OCy6b$,$"$C$F$b$=3D$l$r$&$"$^$o$k%[!<%`$m!<$s!"8e$OCy6bL5$7$G= $9!#=1B(B =1B$BIOK3O7?M$N$?$s$9MB6b#1#0#0#0K|$OIwA0$N$H$b$7$S$J$N$G$9=1B(B : > = =1B$BHs8zN($,$O$S$3$jL14V4k6H$N%$%s%;%s%F%#%V$O0`$(!"9q:]6%AhNO$O=1B(B =1B$B:GBg!"Bg4k6H$N#S#C#M8zN(2=3D$O$=3D$N%7%9%F%`2=3D$K6b$,G|Bg$K7|$+$j=1B= (B =1B$B4XO"2<@A$1; Mon, 2 Sep 2002 03:26:47 -0700 (PDT) Received: from goose.mail.pas.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4416C43E84 for ; Mon, 2 Sep 2002 03:26:47 -0700 (PDT) (envelope-from absinthe@pobox.com) Received: from dhcp068-64-151-24.nt01-c4.cpe.charter-ne.com ([24.151.64.68] helo=laredo.retrovertigo.com) by goose.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17loPu-00020v-00 for freebsd-hackers@freebsd.org; Mon, 02 Sep 2002 03:26:46 -0700 Content-Type: text/plain; charset="us-ascii" From: Dylan Carlson Reply-To: absinthe@pobox.com To: freebsd-hackers@freebsd.org Subject: sysinstall(8) Date: Mon, 2 Sep 2002 06:26:50 -0400 User-Agent: KMail/1.4.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209020626.50876.absinthe@pobox.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Greetings. Is there an existing initiative, spec, or active project to replace sysinstall(8) with something better? I went looking recently and couldn't find anything. In the event no spec exists I would like to help start, or contribute to one. TIA, -- Dylan Carlson [absinthe@pobox.com] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 3:40:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 414FB37B400 for ; Mon, 2 Sep 2002 03:40:42 -0700 (PDT) Received: from south.nanolink.com (south.nanolink.com [217.75.134.10]) by mx1.FreeBSD.org (Postfix) with SMTP id B9B5943E4A for ; Mon, 2 Sep 2002 03:40:40 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 79011 invoked by uid 85); 2 Sep 2002 10:49:03 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.131.130) by south.nanolink.com with SMTP; 2 Sep 2002 10:49:01 -0000 Received: (qmail 9376 invoked by uid 1000); 2 Sep 2002 10:39:36 -0000 Date: Mon, 2 Sep 2002 13:39:36 +0300 From: Peter Pentchev To: Dylan Carlson Cc: freebsd-hackers@freebsd.org Subject: Re: sysinstall(8) Message-ID: <20020902103936.GB367@straylight.oblivion.bg> Mail-Followup-To: Dylan Carlson , freebsd-hackers@freebsd.org References: <200209020626.50876.absinthe@pobox.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <200209020626.50876.absinthe@pobox.com> User-Agent: Mutt/1.5.1i X-Virus-Scanned: by Nik's Monitoring Daemon (AMaViS perl-11d ) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 02, 2002 at 06:26:50AM -0400, Dylan Carlson wrote: > Greetings. >=20 > Is there an existing initiative, spec, or active project to replace=20 > sysinstall(8) with something better? I went looking recently and couldn'= t=20 > find anything. >=20 > In the event no spec exists I would like to help start, or contribute to = one. I agree that it is not immediately obvious, but at the main FreeBSD web site http://www.FreeBSD.org/ go to the Projects page, scroll to the bottom, and in the Misc section there is the FreeBSD libh Project. It just might be what you want :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence didn't exist, somebody would have invented it. --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9cz/o7Ri2jRYZRVMRAimGAJ9bbbb/Xou5VIX8pHzHxzKRmbjDFwCcCTB+ F62+AMQ8qTApBzPwHMISHSs= =BEDN -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 4:42:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9810837B400 for ; Mon, 2 Sep 2002 04:42:12 -0700 (PDT) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A8AC43E81 for ; Mon, 2 Sep 2002 04:42:06 -0700 (PDT) (envelope-from marks@ripe.net) Received: from laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with SMTP id g82Bftgs032069; Mon, 2 Sep 2002 13:41:55 +0200 Received: (nullmailer pid 51236 invoked by uid 1000); Mon, 02 Sep 2002 10:37:47 -0000 Date: Mon, 2 Sep 2002 12:37:47 +0200 From: Mark Santcroos To: Bruce M Simpson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: VMware 3 on FreeBSD? Message-ID: <20020902103747.GA762@laptop.6bone.nl> References: <20020827123054.GF68243@pcwin002.win.tue.nl> <20020828110956.A23979@nebula-bsd.dyndns.org> <20020830082012.GA18902@spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020830082012.GA18902@spc.org> User-Agent: Mutt/1.4i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-Spam-Status: NONE ; -1035 X-RIPE-Spam-Level: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Aug 30, 2002 at 09:20:12AM +0100, Bruce M Simpson wrote: > Having said that though, I have had 3.0 running as well as 2.0, under ^^^^^^^^^^^^^^^^^^^^^^ Can you elaborate a bit more please? Probably your definition of 'running' is less strict than mine. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 4:54:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8FD337B400 for ; Mon, 2 Sep 2002 04:54:26 -0700 (PDT) Received: from smtp01.01.246.ne.jp (smtp01.01.246.ne.jp [210.253.192.39]) by mx1.FreeBSD.org (Postfix) with SMTP id A41FF43E75 for ; Mon, 2 Sep 2002 04:54:25 -0700 (PDT) (envelope-from alad@01.246.ne.jp) Received: (qmail 24738 invoked by alias); 2 Sep 2002 20:54:18 +0900 Received: (qmail 24716 invoked from network); 2 Sep 2002 20:54:17 +0900 Received: from unknown (HELO mebius2) (210.253.214.225) by tp01001 with SMTP; 2 Sep 2002 20:54:17 +0900 Message-ID: <02b001c25276$82beb4f0$0201a8c0@mebius2> From: "alad" To: , "freebsd-hackers@FreeBSD.O" , Cc: , Subject: Date: Mon, 2 Sep 2002 20:47:24 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG =1B$B%"%i%C%I$G$9!#=1B(B =1B$B0J2<#2E@Jg=3D8=1B(B =1B$B#1!%%I%a%$%s%5!<%PC5:w$K$h$k%N!<%I$+$i%N!<%I$N%"%I%l%9DI5a%7%9%F%`$N= =1B(B =1B$BMW7oDj5A=1B(B =1B$B#2!%9q2HDL2_H/9T;Y1gMW7oDj5A=1B(B To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 6:25:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0D8B37B400 for ; Mon, 2 Sep 2002 06:25:13 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id A33C543E3B for ; Mon, 2 Sep 2002 06:25:12 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 3238 invoked by uid 1031); 2 Sep 2002 13:23:52 -0000 Date: Mon, 2 Sep 2002 14:23:51 +0100 From: Bruce M Simpson To: Mark Santcroos Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: VMware 3 on FreeBSD? Message-ID: <20020902132351.GA2409@spc.org> Mail-Followup-To: Bruce M Simpson , Mark Santcroos , freebsd-hackers@FreeBSD.ORG References: <20020827123054.GF68243@pcwin002.win.tue.nl> <20020828110956.A23979@nebula-bsd.dyndns.org> <20020830082012.GA18902@spc.org> <20020902103747.GA762@laptop.6bone.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020902103747.GA762@laptop.6bone.nl> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Sep 02, 2002 at 12:37:47PM +0200, Mark Santcroos wrote: > On Fri, Aug 30, 2002 at 09:20:12AM +0100, Bruce M Simpson wrote: > > Having said that though, I have had 3.0 running as well as 2.0, under > ^^^^^^^^^^^^^^^^^^^^^^ > Can you elaborate a bit more please? Probably your definition of 'running' > is less strict than mine. As in, just dumped the executables onto the box, and had it run - I haven't attempted to run any guest OSes yet. The USB functionality looks like it's going to need either a userland ELF redirection (via the LD_PRELOAD mechanism) to 'pretend' to field Linux usdevfs requests. Either that or we're going to need to port (hack, spit) usbdevfs. The userland solution is probably quicker to punt out and code (map open/ioctl and other syscalls, match by path, onto /dev/ugen*) than porting usbdevfs. Joe Karthausen is talking about making this a project (porting 3.1). Less talk more rock? :-) BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 6:32: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B939037B400 for ; Mon, 2 Sep 2002 06:32:01 -0700 (PDT) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 747F243E72 for ; Mon, 2 Sep 2002 06:32:00 -0700 (PDT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.5/8.12.3) with ESMTP id g82DVxHU068331; Mon, 2 Sep 2002 15:31:59 +0200 (CEST) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.5/8.12.4/Submit) id g82DVxI8068330; Mon, 2 Sep 2002 15:31:59 +0200 (CEST) Date: Mon, 2 Sep 2002 15:31:59 +0200 From: Stijn Hoop To: Bruce M Simpson Cc: freebsd-hackers@freebsd.org Subject: Re: VMware 3 on FreeBSD? Message-ID: <20020902133159.GH89997@pcwin002.win.tue.nl> References: <20020827123054.GF68243@pcwin002.win.tue.nl> <20020828110956.A23979@nebula-bsd.dyndns.org> <20020830082012.GA18902@spc.org> <20020902103747.GA762@laptop.6bone.nl> <20020902132351.GA2409@spc.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ni93GHxFvA+th69W" Content-Disposition: inline In-Reply-To: <20020902132351.GA2409@spc.org> User-Agent: Mutt/1.4i X-Bright-Idea: Let's abolish HTML mail! Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --ni93GHxFvA+th69W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 02, 2002 at 02:23:51PM +0100, Bruce M Simpson wrote: > On Mon, Sep 02, 2002 at 12:37:47PM +0200, Mark Santcroos wrote: > > On Fri, Aug 30, 2002 at 09:20:12AM +0100, Bruce M Simpson wrote: > > > Having said that though, I have had 3.0 running as well as 2.0, under > > ^^^^^^^^^^^^^^^^^^^^^^ > > Can you elaborate a bit more please? Probably your definition of 'runni= ng' > > is less strict than mine. >=20 > As in, just dumped the executables onto the box, and had it run - I haven= 't > attempted to run any guest OSes yet.=20 You have it running?! I'm still struggling to get a vmmon module, without which vmware spits out this indefinitely: VMware Workstation Error: Could not open /dev/vmmon: No such file or directory. Please make sure that the kernel module `vmmon' is loaded. Press "Enter" to continue... I've tried grabbing the sources for the 2.x vmware modules but a lot of patches fail... > The USB functionality looks like it's > going to need either a userland ELF redirection (via the LD_PRELOAD=20 > mechanism) to 'pretend' to field Linux usdevfs requests. Either that or w= e're > going to need to port (hack, spit) usbdevfs. The userland solution is > probably quicker to punt out and code (map open/ioctl and other syscalls, > match by path, onto /dev/ugen*) than porting usbdevfs.=20 Way above my head :) > Joe Karthausen is talking about making this a project (porting 3.1). Less > talk more rock? :-) Trying to, but not succeeding... --Stijn --=20 I wish there was a knob on the TV to turn up the intelligence. There's a k= nob called `brightness', but it doesn't work." -- Gallagher --ni93GHxFvA+th69W Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9c2hOY3r/tLQmfWcRAoS1AJ9naNw5P393H04t1t2bsxwoj87Y/wCgpnoJ /92DXnupMST66HTw5CMn3kI= =KvQV -----END PGP SIGNATURE----- --ni93GHxFvA+th69W-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 6:55:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77F5A37B400 for ; Mon, 2 Sep 2002 06:55:28 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id 6C77F43E4A for ; Mon, 2 Sep 2002 06:55:27 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 28984 invoked by uid 1031); 2 Sep 2002 13:54:07 -0000 Date: Mon, 2 Sep 2002 14:54:06 +0100 From: Bruce M Simpson To: Stijn Hoop Cc: freebsd-hackers@freebsd.org Subject: Re: VMware 3 on FreeBSD? Message-ID: <20020902135406.GC2409@spc.org> Mail-Followup-To: Bruce M Simpson , Stijn Hoop , freebsd-hackers@freebsd.org References: <20020827123054.GF68243@pcwin002.win.tue.nl> <20020828110956.A23979@nebula-bsd.dyndns.org> <20020830082012.GA18902@spc.org> <20020902103747.GA762@laptop.6bone.nl> <20020902132351.GA2409@spc.org> <20020902133159.GH89997@pcwin002.win.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020902133159.GH89997@pcwin002.win.tue.nl> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Sep 02, 2002 at 03:31:59PM +0200, Stijn Hoop wrote: > You have it running?! I'm still struggling to get a vmmon module, without [snip] Ah. I installed the vmware2 port, *then* the vmware3 rpm (using rpm2cpio). This just used the existing vmmon module. I assume more tweaking will be necessary as was the case for vmware2. [snip] > Way above my head :) This is purely speculation as to how USB devices might be handled. BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 7:30:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18D7337B401 for ; Mon, 2 Sep 2002 07:30:33 -0700 (PDT) Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80F6743E65 for ; Mon, 2 Sep 2002 07:30:31 -0700 (PDT) (envelope-from stijn@pcwin002.win.tue.nl) Received: from pcwin002.win.tue.nl (orb_rules@localhost [127.0.0.1]) by pcwin002.win.tue.nl (8.12.5/8.12.3) with ESMTP id g82EUUHU068858; Mon, 2 Sep 2002 16:30:30 +0200 (CEST) (envelope-from stijn@pcwin002.win.tue.nl) Received: (from stijn@localhost) by pcwin002.win.tue.nl (8.12.5/8.12.4/Submit) id g82EUUu3068857; Mon, 2 Sep 2002 16:30:30 +0200 (CEST) Date: Mon, 2 Sep 2002 16:30:30 +0200 From: Stijn Hoop To: Bruce M Simpson Cc: freebsd-hackers@freebsd.org Subject: Re: VMware 3 on FreeBSD? Message-ID: <20020902143030.GK89997@pcwin002.win.tue.nl> References: <20020827123054.GF68243@pcwin002.win.tue.nl> <20020828110956.A23979@nebula-bsd.dyndns.org> <20020830082012.GA18902@spc.org> <20020902103747.GA762@laptop.6bone.nl> <20020902132351.GA2409@spc.org> <20020902133159.GH89997@pcwin002.win.tue.nl> <20020902135406.GC2409@spc.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zgY/UHCnsaNnNXRx" Content-Disposition: inline In-Reply-To: <20020902135406.GC2409@spc.org> User-Agent: Mutt/1.4i X-Bright-Idea: Let's abolish HTML mail! Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --zgY/UHCnsaNnNXRx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 02, 2002 at 02:54:06PM +0100, Bruce M Simpson wrote: > On Mon, Sep 02, 2002 at 03:31:59PM +0200, Stijn Hoop wrote: > > You have it running?! I'm still struggling to get a vmmon module, witho= ut > [snip] >=20 > Ah. I installed the vmware2 port, *then* the vmware3 rpm (using rpm2cpio). > This just used the existing vmmon module. I assume more tweaking will > be necessary as was the case for vmware2. I'll try that tomorrow. The sources for the vmmon-module are a bit different at least, so I'm surprised it works, but I'm ready to give it a try :) > [snip] > > Way above my head :) >=20 > This is purely speculation as to how USB devices might be handled. Maybe someone more in the know can port the usbdevfs (as an aside, is that a Linuxism? Why not use a standard devfs?) --Stijn --=20 Beware of he who would deny you access to information. For in his heart he thinks himself your master. -- Sid Meyer, "Sid Meyer's Alpha Centauri" --zgY/UHCnsaNnNXRx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9c3YGY3r/tLQmfWcRAv1vAJ9/eHZExszCwmzxvkp14QVzrxh/mQCbBehk E79SFS0rVwU5orzIQNa3aHg= =7D7y -----END PGP SIGNATURE----- --zgY/UHCnsaNnNXRx-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 8:50: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C81CB37B400 for ; Mon, 2 Sep 2002 08:50:06 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id 83E4B43E3B for ; Mon, 2 Sep 2002 08:50:04 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 5318 invoked by uid 1031); 2 Sep 2002 15:48:40 -0000 Date: Mon, 2 Sep 2002 16:48:39 +0100 From: Bruce M Simpson To: Stijn Hoop Cc: freebsd-hackers@freebsd.org, joe@freebsd.org Subject: Re: VMware 3 on FreeBSD? Message-ID: <20020902154839.GE2409@spc.org> Mail-Followup-To: Bruce M Simpson , Stijn Hoop , freebsd-hackers@freebsd.org, joe@freebsd.org References: <20020827123054.GF68243@pcwin002.win.tue.nl> <20020828110956.A23979@nebula-bsd.dyndns.org> <20020830082012.GA18902@spc.org> <20020902103747.GA762@laptop.6bone.nl> <20020902132351.GA2409@spc.org> <20020902133159.GH89997@pcwin002.win.tue.nl> <20020902135406.GC2409@spc.org> <20020902143030.GK89997@pcwin002.win.tue.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020902143030.GK89997@pcwin002.win.tue.nl> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Sep 02, 2002 at 04:30:30PM +0200, Stijn Hoop wrote: > > This is purely speculation as to how USB devices might be handled. > > Maybe someone more in the know can port the usbdevfs (as an aside, is > that a Linuxism? Why not use a standard devfs?) usbdevfs is a Linuxism. devfs's semantics are totally different. Porting it would allow Linux native applications, such as VMware and Linux-compiled userland USB drivers, to operate under FreeBSD. It would also mean that proprietary USB devices could be operated within guest operating systems, and perhaps reverse engineered more easily. I think this is one of the things Joe was driving at. BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 10:28:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EE1237B400 for ; Mon, 2 Sep 2002 10:28:10 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id D811743E42 for ; Mon, 2 Sep 2002 10:28:09 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.5/8.12.2) with ESMTP id g82HS4fF014985; Mon, 2 Sep 2002 10:28:04 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.5/8.12.5/Submit) id g82HS2hm014984; Mon, 2 Sep 2002 10:28:02 -0700 (PDT) Date: Mon, 2 Sep 2002 10:28:02 -0700 From: "David O'Brien" To: Terry Lambert Cc: "Brandon D. Valentine" , mark tinguely , akoskine@cc.helsinki.fi, freebsd-hackers@FreeBSD.ORG Subject: Re: More dynamic KVA_SPACE Message-ID: <20020902172802.GB5232@dragon.nuxi.com> Reply-To: obrien@FreeBSD.ORG References: <20020901192245.E1008-100000@taran> <3D72EE54.90EA7977@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D72EE54.90EA7977@mindspring.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, Sep 01, 2002 at 09:51:32PM -0700, Terry Lambert wrote: > The original claims for the tape-out on the x86-64 from AMD so > that this could happen were September 2001, with sample units > 1Q2002. The AMD schedule slipped. LOL! This slippage is *NOTHING* compared to Merced/IA-64. When I was at HP in the summer of _1997_, Merced was going to come out by end of the year. Hum... a slippage of how many years??? I'd say Intel takes the cake for vapor CPU's. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 12:15:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D39237B400 for ; Mon, 2 Sep 2002 12:15:27 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AA8843E42 for ; Mon, 2 Sep 2002 12:15:27 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g82JFQPQ032493 for ; Mon, 2 Sep 2002 12:15:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g82JFQ4h032492; Mon, 2 Sep 2002 12:15:26 -0700 (PDT) (envelope-from dillon) Date: Mon, 2 Sep 2002 12:15:26 -0700 (PDT) From: Matthew Dillon Message-Id: <200209021915.g82JFQ4h032492@apollo.backplane.com> To: hackers@freebsd.org Subject: 64 bit API/ABI changes proposal for -current References: <20020902045105.497FD37B43B@hub.freebsd.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG About 34 system calls need work (with time changes), approximately 16 without time changes. I've included a summary at the end. The questions before us: * What to do about time representation. * Whether to create a new syscall vector or use the existing vector. I have thought long and hard about this and I now believe that we should keep our existing vector, even though it's become a real mess, at least through the release. This will also allow us to convert to a 64 bit time representation without blowing anything up. The original API calls would of course remain valid. wait4() -> wait464() *stat() -> *stat64() getrusage() -> getrusage64() getfsstat() -> getfsstat64() *statfs() -> *statfs64() *itimer() -> *itimer64() select() -> select64() gettimeofday() -> gettimeofday64() settimeofday() -> settimeofday64() *times() -> *times64() adjtime() -> adjtime64() quotactl() -> quotactl64() CREATE sleep64() (takes timeval64) typedef int64_t time64_t; struct timeval64 { time64_t tv_sec; int64_t tv_frac; /* N/2^63 fractional */ }; typedef struct timeval64 timespec64; struct itimerval64 { struct timeval64 it_interval; struct timeval64 it_value; int64_t it_resolution; /* N/2^63 fractional (ro) */ } #define TIMEFRAC 0x4000000000000000LL I understand some people may want this to be unsigned and 0xF[63] or 0x7F[62] but this makes the fractional value an imperfect representation in both base 10 and base 2 and its a good idea to make it a perfect representation in at least base 10 or base 2. Also, divider logic is far faster with fewer '1' bits. In terms of signed verses unsigned it is far easier to use a signed value here in regards to program logic and useage and, additionally, being able to represent negative times is a useful abstraction even if the syscalls do not particularly need the capability. In regards to normalizing the API such that a call to stat() should actually be a call to stat64(), I believe a compiler option may be the best way to go. The compiler option would simply pre-set a #define and our includes would #define-rename the functions to present a normalized API to those programs that can handle it. Example: gcc --unix64 (sets __UNIX_API64__) gcc --unix32 (unsets __UNIX_API64__) (default) Then our system include files would do this (in appropriate places): #ifdef __UNIX_API64__ #define stat stat64 #define ... (etc) #define time_t time64_t #define timeval timeval64 #endif Amoung other things this should hopefully make any issues that come up debuggable by causing the compiler to generate warnings when prototypes do not match up. EVENTUAL GOAL The eventual goal would then be to compile our entire source tree with --unix64 through a release or two, and then, eventually (perhaps two years down the line) we would make --unix64 the default. TIMEVAL64 ISSUES Now there is a fairly serious issue with using fractional seconds, and that is that you cannot use the representation additively. That is, you cannot represent '100ns' in the structure and then add thousands of structures together and get the result you expect because 100ns cannot be represented exactly with this method. This is the same problem that financial systems have when they try to use floating point (e.g. 'double') to add monetary amounts together. If you do not round each intermediate result to the required resolution errors can creep into long calculations. As long as people understand this problem I believe the format is reasonable. -Matt Matthew Dillon (Matt's summary of syscall changes) wait4 extend rusage elements to 64 bits getrusage extend rusage elements to 64 bits getfsstat extend f_blocks, f_bfree, f_bavail, f_files, f_ffree, f_syncwrites, f_asyncwrites, f_syncreads, f_asyncreads to 64 bits, add any additional fields required by Kirk. *statfs various internal fields and time *stat ino_t -> 64 bits, time fields. What about st_gen ? *itimer itimerval contains timeval (also, add an ITIMER_HIRES feature) select timeval passed gettimeofday timeval passed settimeofday timeval passed *times timeval passed adjtime timeval passed quotactl extend dqblk structure to 64 bit limits ntp* Do any of the NTP API elements need to be extended? ntp_adjtime(), ntp_gettime() (well, the sysctl anyway) clock_gettime timespec passed clock_settime timespec passed clock_getres timespec passed nanosleep timespec passed (new function: sleep64()) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 12:21:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 195F937B400 for ; Mon, 2 Sep 2002 12:21:28 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3513543E4A for ; Mon, 2 Sep 2002 12:21:27 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g82JLKvV055266; Mon, 2 Sep 2002 21:21:21 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current In-Reply-To: Your message of "Mon, 02 Sep 2002 12:15:26 PDT." <200209021915.g82JFQ4h032492@apollo.backplane.com> Date: Mon, 02 Sep 2002 21:21:20 +0200 Message-ID: <55265.1030994480@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200209021915.g82JFQ4h032492@apollo.backplane.com>, Matthew Dillon w rites: > struct timeval64 { > time64_t tv_sec; > int64_t tv_frac; /* N/2^63 fractional */ > }; We have this one already, and it's called bintime, except that it correctly uses N/2^64 fractional the way binary computers prefer it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 12:29:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23A8237B400 for ; Mon, 2 Sep 2002 12:29:17 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D58D343E4A for ; Mon, 2 Sep 2002 12:28:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g82JSZPQ032623; Mon, 2 Sep 2002 12:28:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g82JSZNK032622; Mon, 2 Sep 2002 12:28:35 -0700 (PDT) (envelope-from dillon) Date: Mon, 2 Sep 2002 12:28:35 -0700 (PDT) From: Matthew Dillon Message-Id: <200209021928.g82JSZNK032622@apollo.backplane.com> To: Poul-Henning Kamp Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current References: <55265.1030994480@critter.freebsd.dk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> struct timeval64 { :> time64_t tv_sec; :> int64_t tv_frac; /* N/2^63 fractional */ :> }; : :We have this one already, and it's called bintime, except that it :correctly uses N/2^64 fractional the way binary computers prefer it. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Hmm. That's certainly a reasonable point. I suppose a negative representation is still possible if one considers the entire 128 bit word as a 128 bit fractional time. All right, I'll amend the proposal to use 2^64. the fractional element will be unsigned, the tv_sec will remain signed. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 12:33:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEABA37B400 for ; Mon, 2 Sep 2002 12:33:20 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7BA443E6A for ; Mon, 2 Sep 2002 12:33:19 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g82JXGvV055510; Mon, 2 Sep 2002 21:33:16 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current In-Reply-To: Your message of "Mon, 02 Sep 2002 12:28:35 PDT." <200209021928.g82JSZNK032622@apollo.backplane.com> Date: Mon, 02 Sep 2002 21:33:16 +0200 Message-ID: <55509.1030995196@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200209021928.g82JSZNK032622@apollo.backplane.com>, Matthew Dillon w rites: > >:> struct timeval64 { >:> time64_t tv_sec; >:> int64_t tv_frac; /* N/2^63 fractional */ >:> }; >: >:We have this one already, and it's called bintime, except that it >:correctly uses N/2^64 fractional the way binary computers prefer it. >: >:-- >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > Hmm. That's certainly a reasonable point. I suppose a negative > representation is still possible if one considers the entire 128 > bit word as a 128 bit fractional time. > > All right, I'll amend the proposal to use 2^64. the fractional > element will be unsigned, the tv_sec will remain signed. That is exactly how bintime is defined :-) struct bintime { time_t sec; uint64_t frac; }; If I had a int128_t, I would have used that instead... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 12:42:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E866037B400 for ; Mon, 2 Sep 2002 12:42:26 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D3AD43E3B for ; Mon, 2 Sep 2002 12:42:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g82JgIPQ032729; Mon, 2 Sep 2002 12:42:18 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g82JgIZn032728; Mon, 2 Sep 2002 12:42:18 -0700 (PDT) (envelope-from dillon) Date: Mon, 2 Sep 2002 12:42:18 -0700 (PDT) From: Matthew Dillon Message-Id: <200209021942.g82JgIZn032728@apollo.backplane.com> To: Poul-Henning Kamp Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current References: <55509.1030995196@critter.freebsd.dk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> :> All right, I'll amend the proposal to use 2^64. the fractional :> element will be unsigned, the tv_sec will remain signed. : :That is exactly how bintime is defined :-) : : struct bintime { : time_t sec; : uint64_t frac; : }; : :If I had a int128_t, I would have used that instead... : : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Ok, we have an issue in regards to libc/user function visibility. The bintime structures and functions are surrounded by __BSD_VISIBLE. The question to you and to the list in general is: what to call the user-visible structure. 'bintime' is a cute name, I certainly like it better then timeval64, and we could probably get away with calling the user visible structure bintime, but I don't know if we can get away with including all the supporting inline functions (not that we necessarily have to include them for the syscall work, but it would be nice). Also, the in-kernel time_t is 32 bits on 32 bit architectures so bintime is not compatible as-is, but it would not be much work to make bintime use time64_t. We can't create yet another userland time structure without making seconds 64 bits. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 12:50:19 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F31137B406 for ; Mon, 2 Sep 2002 12:50:07 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 000F043E97 for ; Mon, 2 Sep 2002 12:49:36 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g82Jn9vV055777; Mon, 2 Sep 2002 21:49:09 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current In-Reply-To: Your message of "Mon, 02 Sep 2002 12:42:18 PDT." <200209021942.g82JgIZn032728@apollo.backplane.com> Date: Mon, 02 Sep 2002 21:49:09 +0200 Message-ID: <55776.1030996149@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <200209021942.g82JgIZn032728@apollo.backplane.com>, Matthew Dillon w rites: > Ok, we have an issue in regards to libc/user function visibility. > The bintime structures and functions are surrounded by __BSD_VISIBLE. That was an attempt at preventive debrucification :-) > The question to you and to the list in general is: what to call the > user-visible structure. 'bintime' is a cute name, I certainly like > it better then timeval64, and we could probably get away with calling > the user visible structure bintime, but I don't know if we can get > away with including all the supporting inline functions (not that we > necessarily have to include them for the syscall work, but it would > be nice). One of the thing which irks me about timeval and timespec is that the perfectly useable and practically needed functions for adding, subtracting and normalizing them are not allowed in the .h in POSIX. POSIX sucks in many cases like that: It defines just enough to cramp future improvement, but not enough to facilitate current usability :-( When I first encountered POSIXMISTAKE many years ago I thought it kind of rude, now I'm tempted to invert the sign and introduce "POSIXGOTTHISRIGHT", it would be far less intrusive. The right thing to do is probably to introduce which is pulled into and possibly unless people insist on getting pure-to-the-heart-POSIX-includes. > Also, the in-kernel time_t is 32 bits on 32 bit architectures so bintime > is not compatible as-is, but it would not be much work to make > bintime use time64_t. We can't create yet another userland time > structure without making seconds 64 bits. It was my expectation that time_t would become 64 bits in the kernel, rather than have to s/time_t/time64_t throughout the kernel. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 12:52:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA3E237B400 for ; Mon, 2 Sep 2002 12:52:37 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3996443E4A for ; Mon, 2 Sep 2002 12:52:33 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 87E272A88D; Mon, 2 Sep 2002 12:52:29 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: hackers@freebsd.org Subject: Re: 64 bit API/ABI changes proposal for -current In-Reply-To: <200209021915.g82JFQ4h032492@apollo.backplane.com> Date: Mon, 02 Sep 2002 12:52:29 -0700 From: Peter Wemm Message-Id: <20020902195229.87E272A88D@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > About 34 system calls need work (with time changes), approximately > 16 without time changes. I've included a summary at the end. > > The questions before us: > > * What to do about time representation. > > * Whether to create a new syscall vector or use the existing > vector. > > I have thought long and hard about this and I now believe that we > should keep our existing vector, even though it's become a real mess, > at least through the release. This will also allow us to convert > to a 64 bit time representation without blowing anything up. The > original API calls would of course remain valid. > > wait4() -> wait464() > *stat() -> *stat64() > getrusage() -> getrusage64() > getfsstat() -> getfsstat64() > *statfs() -> *statfs64() > *itimer() -> *itimer64() > select() -> select64() > gettimeofday() -> gettimeofday64() > settimeofday() -> settimeofday64() > *times() -> *times64() > adjtime() -> adjtime64() > quotactl() -> quotactl64() Matt, I realize you have thought long and hard about this, but I want to make a couple of points. 1) 32 bit i386 already has its fate sealed. AMD are switching to 64 bit, and Intel are doing the same (either x86-64 or their own 64 bit environment, depending on which rumors you listen to). 2) Many of these calls *are* 64 bit already on 64 bit platforms. Adding an additional layer here just makes life harder when we 64 bit is the norm. For example, get/settimeofday, *itimer, select, etc etc use timeval: struct timeval { long tv_sec; /* seconds */ long tv_usec; /* and microseconds */ }; and that, folks, is 64 bit on 64 bit platforms already. 3) 5.0 is not going to last till anywhere near year 2038. In the next year, or two at tops, it is going to be perfectly clear what the future of common 64 bit hardware will look like 4) Changing time_t to 64 bit using long long on a native 32 bit platform is a f*cking nightmare. I've tried this and it got very nasty very quickly. 5) Changing time_t to 64 bit is trivial on a native 64 bit platform. I have done this on an ia64 machine. The sparc64 folks indicated they wanted to do the same. Much of the work has been done already. I worry that jumping in prematurely will leave us with a legacy issues that will haunt us for year and years to come, while the linux folks laugh at our pain and convoluted API's because they've already set their internal time_t to 64 bit on their 64 bit platforms. I urge folks to hold off just a bit longer so that we can get 5.x stable and in shape and released without blowing up 50% of our ports due to long long time_t problems. re@ is already having nightmares about 5.0, we do not need this thrown into the mix yet. Especially when the right solution will become more obvious as the 64 bit desktop machine dust settles. Also, hackers@ is really not the place for this. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 14: 4:56 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E5CB37B400 for ; Mon, 2 Sep 2002 14:04:49 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 165B343E65 for ; Mon, 2 Sep 2002 14:04:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g82L4mPQ033102; Mon, 2 Sep 2002 14:04:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g82L4mdf033101; Mon, 2 Sep 2002 14:04:48 -0700 (PDT) (envelope-from dillon) Date: Mon, 2 Sep 2002 14:04:48 -0700 (PDT) From: Matthew Dillon Message-Id: <200209022104.g82L4mdf033101@apollo.backplane.com> To: Peter Wemm Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current References: <20020902195229.87E272A88D@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Matt, I realize you have thought long and hard about this, but I want to :make a couple of points. : :1) 32 bit i386 already has its fate sealed. AMD are switching to 64 bit, :and Intel are doing the same (either x86-64 or their own 64 bit environment, :depending on which rumors you listen to). This is wishful thinking, which I will elaborate on below. :2) Many of these calls *are* 64 bit already on 64 bit platforms. Adding :an additional layer here just makes life harder when we 64 bit is the norm. :For example, get/settimeofday, *itimer, select, etc etc use timeval: :struct timeval { : long tv_sec; /* seconds */ : long tv_usec; /* and microseconds */ :}; :and that, folks, is 64 bit on 64 bit platforms already. : :3) 5.0 is not going to last till anywhere near year 2038. In the next year, :or two at tops, it is going to be perfectly clear what the future of common :64 bit hardware will look like Ok, now wait a second. First of all our time_t problems do not start in 2038. THEY ARE ALREADY HERE. A 32 bit time_t is an unusable representation for a growing number of applications. Simulations, forward looking contract time/date representation, databases, hell even my USENET news server uses a 64 bit time representation internally. Second, by far the most important reason for giving 32 bit platforms a 64 bit time capability is software portability, and that is an issue NOW. People who develop software on 32 bit platforms do not have universal access to 64 bit platforms in order to ensure that their code works. Every single application I've written that uses time_t heavily has required modifications when ported to a 64 bit platform, even though I tried to take into account 64 bit time_t's in the development of the software. Being able to write an application that uses 64 bit time_t's on a 32 bit platform now is therefore an important goal. Third, you have a very short term view of the longevity of software. Software I wrote 10 years ago is likely to still be in operation in 2038. One of the new products I am working on uses PC/104 technology and some of those units are almost guarenteed to still be in operation in 2037. When 2037 comes rolling around I'm not likely to want to pull out the "old source" and try to "make it work". This is a problem for me *NOW*, not in 2038. But NOW. Forth, FreeBSD is used heavily in the embedded world and the intention seems to be to make it even more useable. A good chunk of the embedded world will almost certainly still be using 32 bit platforms in 2038. 64 bits is great, but 64 bits eats a great deal of electrical power. This is why you still see little 8 bit cpus in the embedded world today. 32 bit platforms are likely to be in major use in 2038. :4) Changing time_t to 64 bit using long long on a native 32 bit platform :is a f*cking nightmare. I've tried this and it got very nasty very quickly. This is not what I proposed. I proposed adding new system calls to completely and permanently fix all of our outstanding issues and then providing a compiler option to allow developers to select which API they want presented. I'm not sure what the correct solution is but I am sure that we need one, and that we should do at least the kernel bits to support a solution for the 5.0 release. But I will tell you something... I am not a fan of basic system data types changing sizes whether you happen to be running your software on a 32 bit platform or a 64 bit platform. Our off_t works extremely well simply because it's big enough and because it is the same across all platforms. Until we are able to supply kernel support for similar functionality with other data types - time specifications, inodes, block numbers, and so forth, our API and ABI will remain broken in my view. :5) Changing time_t to 64 bit is trivial on a native 64 bit platform. I :have done this on an ia64 machine. The sparc64 folks indicated they wanted :to do the same. Much of the work has been done already. : :I worry that jumping in prematurely will leave us with a legacy issues that :will haunt us for year and years to come, while the linux folks laugh at :our pain and convoluted API's because they've already set their internal :time_t to 64 bit on their 64 bit platforms. : :I urge folks to hold off just a bit longer so that we can get 5.x stable :and in shape and released without blowing up 50% of our ports due to long :long time_t problems. re@ is already having nightmares about 5.0, we do :not need this thrown into the mix yet. Especially when the right solution :will become more obvious as the 64 bit desktop machine dust settles. Again, nothing I proposed would have any effect on our ports. All of my proposals to date are designed to avoid screwing up -current. Perhaps you need to read my posting(s) a bit more carefully. I am still completely open to other solutions, including creating a new syscall vector and allowing a native 32 or 64 bit API to be chosen as a compile-time option, but I do not believe that putting off the whole affair is any sort of solution. -Matt Matthew Dillon :Also, hackers@ is really not the place for this. : :Cheers, :-Peter :-- :Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com :"All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 14:27:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C615137B400 for ; Mon, 2 Sep 2002 14:27:12 -0700 (PDT) Received: from omta01.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1455843E6E for ; Mon, 2 Sep 2002 14:27:03 -0700 (PDT) (envelope-from millon@thatdam.vientiane.net) Received: from sitemail.everyone.net (dsnat [216.200.145.62]) by omta01.mta.everyone.net (Postfix) with ESMTP id 978D21C90EA for ; Mon, 2 Sep 2002 14:26:35 -0700 (PDT) Received: by sitemail.everyone.net (Postfix, from userid 99) id 68C6E3968; Mon, 2 Sep 2002 14:26:35 -0700 (PDT) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Mon, 2 Sep 2002 14:26:35 -0700 (PDT) From: Datthew Millon To: hackers@freebsd.org Subject: 128 bit API/ABI changes proposal for -current Reply-To: millon@thatdam.vientiane.net X-Originating-Ip: [12.153.68.131] Message-Id: <20020902212635.68C6E3968@sitemail.everyone.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG + All this info is released under the superior PPL (Phuck Phumerola License) About 34 system calls need work (with time changes), approximately 16 without time changes. I've included a summary at the end. The questions before us: * What to do about time representation. * Whether to create a new syscall vector or use the existing vector. I have thought long and hard about this and I now believe that we should keep our existing vector, even though it's become a real mess, at least through the release. This will also allow us to convert to a 128 bit time representation without blowing anything up. The original API calls would of course remain valid. wait4() -> wait4128() *stat() -> *stat128() getrusage() -> getrusage128() getfsstat() -> getfsstat128() *statfs() -> *statfs128() *itimer() -> *itimer128() select() -> select128() gettimeofday() -> gettimeofday128() settimeofday() -> settimeofday128() *times() -> *times128() adjtime() -> adjtime128() quotactl() -> quotactl128() CREATE sleep128() (takes timeval128) typedef int128_t time128_t; struct timeval128 { time128_t tv_sec; int128_t tv_frac; /* N/2^127 fractional */ }; typedef struct timeval128 timespec128; struct itimerval128 { struct timeval128 it_interval; struct timeval128 it_value; int128_t it_resolution; /* N/2^127 fractional (ro) */ } #define TIMEFRAC 0x4000000000000000LL I understand some people may want this to be unsigned and 0x1F[127] or 0x7F[62] but this makes the fractional value an imperfect representation in both base 10 and base 2 and its a good idea to make it a perfect representation in at least base 10 or base 2. Also, divider logic is far faster with fewer '1' bits. In terms of signed verses unsigned it is far easier to use a signed value here in regards to program logic and useage and, additionally, being able to represent negative times is a useful abstraction even if the syscalls do not particularly need the capability. In regards to normalizing the API such that a call to stat() should actually be a call to stat128(), I believe a compiler option may be the best way to go. The compiler option would simply pre-set a #define and our includes would #define-rename the functions to present a normalized API to those programs that can handle it. Example: gcc --unix128 (sets __UNIX_API128__) gcc --unix32 (unsets __UNIX_API128__) (default) Then our system include files would do this (in appropriate places): #ifdef __UNIX_API128__ #define stat stat128 #define ... (etc) #define time_t time128_t #define timeval timeval128 #endif Amoung other things this should hopefully make any issues that come up debuggable by causing the compiler to generate warnings when prototypes do not match up. EVENTUAL GOAL The eventual goal would then be to compile our entire source tree with --unix64 through a release or two, and then, eventually (perhaps two years down the line) we would make --unix128 the default. TIMEVAL128 ISSUES Now there is a fairly serious issue with using fractional seconds, and that is that you cannot use the representation additively. That is, you cannot represent '100ns' in the structure and then add thousands of structures together and get the result you expect because 100ns cannot be represented exactly with this method. This is the same problem that financial systems have when they try to use floating point (e.g. 'double') to add monetary amounts together. If you do not round each intermediate result to the required resolution errors can creep into long calculations. As long as people understand this problem I believe the format is reasonable. -Datt Datthew Millon (Matt's summary of syscall changes) wait4 extend rusage elements to 64 bits getrusage extend rusage elements to 64 bits getfsstat extend f_blocks, f_bfree, f_bavail, f_files, f_ffree, f_syncwrites, f_asyncwrites, f_syncreads, f_asyncreads to 64 bits, add any additional fields required by Kirk. *statfs various internal fields and time *stat ino_t -> 64 bits, time fields. What about st_gen ? *itimer itimerval contains timeval (also, add an ITIMER_HIRES feature) select timeval passed gettimeofday timeval passed settimeofday timeval passed *times timeval passed adjtime timeval passed quotactl extend dqblk structure to 64 bit limits ntp* Do any of the NTP API elements need to be extended? ntp_adjtime(), ntp_gettime() (well, the sysctl anyway) clock_gettime timespec passed clock_settime timespec passed clock_getres timespec passed nanosleep timespec passed (new function: sleep64()) _____________________________________________________________ @thatdam.vientiane.net Free Webmail Accounts @ http://www.Vientiane.net/ _____________________________________________________________ Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net http://www.everyone.net/?btn=tag To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 14:31:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A240037B400 for ; Mon, 2 Sep 2002 14:31:49 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A43243E4A for ; Mon, 2 Sep 2002 14:31:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g82LVmPQ033889; Mon, 2 Sep 2002 14:31:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g82LVm1Y033888; Mon, 2 Sep 2002 14:31:48 -0700 (PDT) (envelope-from dillon) Date: Mon, 2 Sep 2002 14:31:48 -0700 (PDT) From: Matthew Dillon Message-Id: <200209022131.g82LVm1Y033888@apollo.backplane.com> To: Peter Wemm Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current References: <20020902195229.87E272A88D@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG My original proposal, before this one, was to create a separate ABI for all the new calls, which also means creating a duplicate set of libraries. I'm still game to do that -- it could be controlled by a make.conf variable and selectable via a compiler option. If we maintain timeval and timespec (except for the 64 bit time_t) then we have full portability. The only real work required inside the kernel is to make the kernel internal time representation 64 bits unconditionally, which is not a big deal, and to implement the syscall abstraction that was proposed in the "stack gap" thread by Ian Dowse. Then the ABI works becomes far easier. This work is mostly just rearranging existing code a little, not implementing new algorithms, and I don't see how it could possibly break -current. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 14:54:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEDCE37B409 for ; Mon, 2 Sep 2002 14:53:59 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3389543E75 for ; Mon, 2 Sep 2002 14:53:59 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id E3A992A893; Mon, 2 Sep 2002 14:53:58 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current In-Reply-To: <200209022104.g82L4mdf033101@apollo.backplane.com> Date: Mon, 02 Sep 2002 14:53:58 -0700 From: Peter Wemm Message-Id: <20020902215358.E3A992A893@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > :4) Changing time_t to 64 bit using long long on a native 32 bit platform > :is a f*cking nightmare. I've tried this and it got very nasty very quickly. > > This is not what I proposed. I proposed adding new system calls to > completely and permanently fix all of our outstanding issues and then > providing a compiler option to allow developers to select which API > they want presented. Well, one thing that I would not be against is a clean divorce of the syscall layer and libc. That then gives us the freedom to implement alternative API selections etc at compile time pretty easily. I just really do not want to see this sort of thing turning up: time_t foo = time(0); printf("the time is %lld\n", (long long)foo); /* i386 compatability */ .. because that hurts our 64 bit platforms down the road when long long becomes 128 bit. intmax_t/%j etc has similar problems as it then takes the native 64 bit time type (long) and converts it to a synthetic 128 bit type. ie: %j and intmax_t etc are just as bad. My first exposure to a unix OS had some pretty horrific stat structure versioning and evilness (svr4). It was a real nightmare, except you never got to wake up and discover that it was all over. I am not against providing 64 bit extentions for 32 bit systems, but it really needs to be done so that it all becomes a giant NOP when on native 64 bit systems. Something like the large-file-summit API extensions that all magically go away after the transition period or when you get a chance to do a total ABI breakaway. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 15: 7:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73C3937B400 for ; Mon, 2 Sep 2002 15:07:25 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D950843E65 for ; Mon, 2 Sep 2002 15:07:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g82M7OPQ034139; Mon, 2 Sep 2002 15:07:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g82M7OAe034138; Mon, 2 Sep 2002 15:07:24 -0700 (PDT) (envelope-from dillon) Date: Mon, 2 Sep 2002 15:07:24 -0700 (PDT) From: Matthew Dillon Message-Id: <200209022207.g82M7OAe034138@apollo.backplane.com> To: Peter Wemm Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current References: <20020902215358.E3A992A893@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :Well, one thing that I would not be against is a clean divorce of the :syscall layer and libc. That then gives us the freedom to implement :alternative API selections etc at compile time pretty easily. : :I just really do not want to see this sort of thing turning up: : : time_t foo = time(0); : printf("the time is %lld\n", (long long)foo); /* i386 compatability */ : :.. because that hurts our 64 bit platforms down the road when long long :becomes 128 bit. intmax_t/%j etc has similar problems as it then takes :the native 64 bit time type (long) and converts it to a synthetic 128 bit :type. ie: %j and intmax_t etc are just as bad. : :My first exposure to a unix OS had some pretty horrific stat structure :versioning and evilness (svr4). It was a real nightmare, except you never :got to wake up and discover that it was all over. : :I am not against providing 64 bit extentions for 32 bit systems, but it :really needs to be done so that it all becomes a giant NOP when on native :64 bit systems. Something like the large-file-summit API extensions that :all magically go away after the transition period or when you get a chance :to do a total ABI breakaway. : :Cheers, :-Peter :-- :Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com Well, then what we want is a new syscall vector, duplicate libraries, and a compiler option, and leave all the function names the same (which means no bintime but allows us to retain everything else). -current would release supporting both with the compiler option defaulting to --unix32 on the IA32 and --unix64 on 64 bit platforms, and then down the line the compiler option would default to --unix64 on all platforms, and then down the line a little more the original syscall vector would become a compatibility option that most people leave out. If we do a clean cut of the ABI for the alpha, sparc, etc... for things like ino_t, which I think we can get away with, then this all becomes a big NOP on 64 bit platforms and eventually becomes a NOP (only one library set and syscall vector is generated) on 32 bit platforms. If we include the other structural changes... 64 bit ino_t in *stat() for example, in only the --unix64 ABI, then we encourage (but do not require) developers to migrate to the ABI. printf("the time is %lld\n"...) is a problem that will *NEVER* go away short of defining a format character to represent time_t itself. The assumption that time_t is somehow tied to a 'long' is broken, pure and simple. I actually think %j is workable, because I don't know a single case of 'speed critical code' where you have a *printf() call passing a time_t. It's very rare, and at least now GCC will catch type size mismatches. The advantage of all of this is that the 32 bit code stays intact and compatible in both source and binary forms, which means no further disruption of -current, just a lot of ABI work on my part. I already did a dry run of the libc changes necessary and given the chance to adjust things incrementally (which can be done with this methodology), it's a lot of grunt work but nothing that I couldn't do in a few weeks. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 15: 8:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 793D137B400 for ; Mon, 2 Sep 2002 15:08:50 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id F18A043E6E for ; Mon, 2 Sep 2002 15:08:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g82M8nPQ034149; Mon, 2 Sep 2002 15:08:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g82M8nql034148; Mon, 2 Sep 2002 15:08:49 -0700 (PDT) (envelope-from dillon) Date: Mon, 2 Sep 2002 15:08:49 -0700 (PDT) From: Matthew Dillon Message-Id: <200209022208.g82M8nql034148@apollo.backplane.com> To: Peter Wemm Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current References: <20020902215358.E3A992A893@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Oops, let me clarify what I mean by 'duplicate libraries'. I do *NOT* mean duping the source code, I simply mean duping the compile run in the buildworld, one for --unix32, one for --unix64, for 32 bit platforms. 64 bit platforms would require no library duplication at all (that being the idea), nor will 32 bit platforms down the line when the old 32 bit interface becomes a compatibility option. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 15:36:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAD5837B400 for ; Mon, 2 Sep 2002 15:36:34 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E55D43E6A for ; Mon, 2 Sep 2002 15:36:34 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 6DFFD2A88D; Mon, 2 Sep 2002 15:36:34 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current In-Reply-To: <200209022207.g82M7OAe034138@apollo.backplane.com> Date: Mon, 02 Sep 2002 15:36:34 -0700 From: Peter Wemm Message-Id: <20020902223634.6DFFD2A88D@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Well, then what we want is a new syscall vector, duplicate libraries, > and a compiler option, and leave all the function names the same > (which means no bintime but allows us to retain everything else). > -current would release supporting both with the compiler option > defaulting to --unix32 on the IA32 and --unix64 on 64 bit platforms, > and then down the line the compiler option would default to --unix64 > on all platforms, and then down the line a little more the original > syscall vector would become a compatibility option that most people > leave out. Argh! This is way overkill. It is *not* what I was advocating. The time to do this is when we bump libc's major number, not duplicating libraries etc. That's a worst case outcome especially when it isn't needed. It would be far less disruptive to add an additional group of 64 bit time aware API's that are optional and portable. Leave the standards-defined API's alone. For example, in your previous suggestion, you had: typedef int64_t time64_t; struct timeval64 { time64_t tv_sec; int64_t tv_frac; /* N/2^63 fractional */ }; #ifdef __UNIX_API64__ #define timeval timeval64 #endif You simply *cannot do this* and remain posix compliant on 64 bit machines. We do not just go and change posix api's just for the sake of leaving out a "64" in a name. If you are going to modify code to use tv_frac, then you may as well refer to it in a 'struct timeval64' and be done with it. I suspect there would be far less confusion if they were not named so closely to their standardized counterparts. Changing code to work with --unix64 on 32 bit systems becomes useless when we have 64 bit native systems, because we then need to un-port it.. (remember --unix64 changes struct timeval.tv_usec to .tv_frac, so code that is "cleaned" to work on --unix64 will no longer compile on a native 64 bit posix compliant environment) Maybe I'm getting all upset about nothing, but you are scaring the hell out of me so far. > The advantage of all of this is that the 32 bit code stays intact and > compatible in both source and binary forms, which means no further > disruption of -current, just a lot of ABI work on my part. I already > did a dry run of the libc changes necessary and given the chance to > adjust things incrementally (which can be done with this methodology), > it's a lot of grunt work but nothing that I couldn't do in a few weeks. Well, I'd like to see a working prototype before anything is committed. Changes in this area are of massive importance to the whole project, so we *must* get it right and agreed apon, or leave it alone. It would also be really good if you could get some buy-in from the other *bsd/linux folks. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 16: 8:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F370E37B400 for ; Mon, 2 Sep 2002 16:08:09 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81FE943E6A for ; Mon, 2 Sep 2002 16:08:09 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g82N89PQ038012; Mon, 2 Sep 2002 16:08:09 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g82N896t038011; Mon, 2 Sep 2002 16:08:09 -0700 (PDT) (envelope-from dillon) Date: Mon, 2 Sep 2002 16:08:09 -0700 (PDT) From: Matthew Dillon Message-Id: <200209022308.g82N896t038011@apollo.backplane.com> To: Peter Wemm , hackers@freebsd.org Subject: Re: 64 bit API/ABI changes proposal for -current References: <20020902223634.6DFFD2A88D@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter, you are again not reading what I'm posting carefully enough. I said very specifically that we wouldn't be using the fractional stuff for this case. Additionally, you are making the assumption that --unix64 and --unix32 are so different from each other that the same code cannot compile to both targets. This is not true either. The only difference is that a couple of types, such as time_t and ino_t, would be extended to 64 bits. The same source will be able to compile to both targets. (in fact, our existing source can almost do this already). Perhaps I am putting too much information out here. The idea of this discussion is to DISCUSS, I am simply creating a starting point for the discussion. None of this stuff is set in stone so screaming at me telling me the whole enchilada will not work because of a few things in here is not going to be productive. Instead you should simply advocate that the interfering items be removed to make the rest work, or something like that. I'm also not sure what you mean when you say "overkill". What you seem to be proposing is an incompatible change to the API and ABI. Sure we can fix all the code in /usr/src, but ports are another matter. What I am proposing does not initially interfere (or need to interfere ) with ports. Finally, in regards to a 'working prototype', please note that what I am proposing is designed to be an incremental process precisely because the whole enchilada is too big to create a 'working prototype' before committing. The project can be cut into many small incremental, non destructive pieces which are comitted incrementally. That's the whole point. You and others may like to do wholely working prototypes in P4 and then smash the whole thing into -current but that isn't how I work. So, no, I am not going to go about it that way. -Matt Matthew Dillon :Matthew Dillon wrote: : :> Well, then what we want is a new syscall vector, duplicate libraries, :> and a compiler option, and leave all the function names the same :> (which means no bintime but allows us to retain everything else). :> -current would release supporting both with the compiler option :> defaulting to --unix32 on the IA32 and --unix64 on 64 bit platforms, :> and then down the line the compiler option would default to --unix64 :> on all platforms, and then down the line a little more the original :> syscall vector would become a compatibility option that most people :> leave out. : :Argh! This is way overkill. It is *not* what I was advocating. : :The time to do this is when we bump libc's major number, not duplicating :libraries etc. That's a worst case outcome especially when it isn't needed. : :It would be far less disruptive to add an additional group of 64 bit :time aware API's that are optional and portable. Leave the standards-defined :API's alone. : :For example, in your previous suggestion, you had: : typedef int64_t time64_t; : struct timeval64 { : time64_t tv_sec; : int64_t tv_frac; /* N/2^63 fractional */ : }; : #ifdef __UNIX_API64__ : #define timeval timeval64 : #endif : :You simply *cannot do this* and remain posix compliant on 64 bit machines. :We do not just go and change posix api's just for the sake of leaving out a :"64" in a name. If you are going to modify code to use tv_frac, then you :may as well refer to it in a 'struct timeval64' and be done with it. :I suspect there would be far less confusion if they were not named so closely :to their standardized counterparts. : :Changing code to work with --unix64 on 32 bit systems becomes useless :when we have 64 bit native systems, because we then need to un-port it.. :(remember --unix64 changes struct timeval.tv_usec to .tv_frac, so code that :is "cleaned" to work on --unix64 will no longer compile on a native :64 bit posix compliant environment) : :Maybe I'm getting all upset about nothing, but you are scaring the hell :out of me so far. : :> The advantage of all of this is that the 32 bit code stays intact and :> compatible in both source and binary forms, which means no further :> disruption of -current, just a lot of ABI work on my part. I already :> did a dry run of the libc changes necessary and given the chance to :> adjust things incrementally (which can be done with this methodology), :> it's a lot of grunt work but nothing that I couldn't do in a few weeks. : :Well, I'd like to see a working prototype before anything is committed. :Changes in this area are of massive importance to the whole project, so we :*must* get it right and agreed apon, or leave it alone. It would also be :really good if you could get some buy-in from the other *bsd/linux folks. : :Cheers, :-Peter :-- :Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com :"All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 16:23:13 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEF0F37B400 for ; Mon, 2 Sep 2002 16:23:11 -0700 (PDT) Received: from horsey.gshapiro.net (horsey.gshapiro.net [209.220.147.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09C7E43E65 for ; Mon, 2 Sep 2002 16:23:11 -0700 (PDT) (envelope-from gshapiro@gshapiro.net) Received: from horsey.gshapiro.net (gshapiro@localhost [IPv6:::1]) by horsey.gshapiro.net (8.12.6.Beta0/8.12.6.Beta1) with ESMTP id g82NNA6X040409 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Sep 2002 16:23:10 -0700 (PDT) Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.12.6.Beta0/8.12.6.Beta1/Submit) id g82NNAMm040406; Mon, 2 Sep 2002 16:23:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15731.62174.39609.240456@horsey.gshapiro.net> Date: Mon, 2 Sep 2002 16:23:10 -0700 From: Gregory Neil Shapiro To: "Eric Parusel" Cc: Subject: Re: why does this sendmail connection take so long? In-Reply-To: <02ec01c25246$2c207c30$076d5118@beair> References: <3D6E243B.1515.8EB744E7@localhost> <3D6E2D31.29065.8EDA44C7@localhost> <15726.26491.969569.176848@horsey.gshapiro.net> <20020902002605.GB38501@dragon.nuxi.com> <02ec01c25246$2c207c30$076d5118@beair> X-Mailer: VM 7.03 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG lists> Now just if I could get Sendmail to not do those dang identd checks lists> all the time... Add this to your .mc file: define(`confTO_IDENT', `0') To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 17:26:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65E3937B400; Mon, 2 Sep 2002 17:26:14 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EEEB43E65; Mon, 2 Sep 2002 17:26:14 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0137.cvx40-bradley.dialup.earthlink.net ([216.244.42.137] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17m1WC-0007Pz-00; Mon, 02 Sep 2002 17:26:08 -0700 Message-ID: <3D740164.B5EB3D1F@mindspring.com> Date: Mon, 02 Sep 2002 17:25:08 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: obrien@FreeBSD.ORG Cc: "Brandon D. Valentine" , mark tinguely , akoskine@cc.helsinki.fi, freebsd-hackers@FreeBSD.ORG Subject: Re: More dynamic KVA_SPACE References: <20020901192245.E1008-100000@taran> <3D72EE54.90EA7977@mindspring.com> <20020902172802.GB5232@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David O'Brien wrote: > > On Sun, Sep 01, 2002 at 09:51:32PM -0700, Terry Lambert wrote: > > The original claims for the tape-out on the x86-64 from AMD so > > that this could happen were September 2001, with sample units > > 1Q2002. The AMD schedule slipped. > > LOL! This slippage is *NOTHING* compared to Merced/IA-64. When I was > at HP in the summer of _1997_, Merced was going to come out by end of the > year. Hum... a slippage of how many years??? I'd say Intel takes the > cake for vapor CPU's. Oh, no question that I'm not happy with hardware vendors. Hence the rant against them... 8-) 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 17:41:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6379137B400 for ; Mon, 2 Sep 2002 17:41:42 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E71843E65 for ; Mon, 2 Sep 2002 17:41:38 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0137.cvx40-bradley.dialup.earthlink.net ([216.244.42.137] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17m1ku-00045s-00; Mon, 02 Sep 2002 17:41:20 -0700 Message-ID: <3D7404F5.B316FBA4@mindspring.com> Date: Mon, 02 Sep 2002 17:40:21 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Poul-Henning Kamp , hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current References: <55509.1030995196@critter.freebsd.dk> <200209021942.g82JgIZn032728@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Ok, we have an issue in regards to libc/user function visibility. > The bintime structures and functions are surrounded by __BSD_VISIBLE. > > The question to you and to the list in general is: what to call the > user-visible structure. 'bintime' is a cute name, I certainly like > it better then timeval64, and we could probably get away with calling > the user visible structure bintime, but I don't know if we can get > away with including all the supporting inline functions (not that we > necessarily have to include them for the syscall work, but it would > be nice). What do Linux, Solaris, SCO, etc. call it? Whatever it is, it should be the same, so that source code does not need to be "#if"'ed. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 18:32:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4144B37B400 for ; Mon, 2 Sep 2002 18:32:34 -0700 (PDT) Received: from goose.mail.pas.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1687F43E65 for ; Mon, 2 Sep 2002 18:32:33 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0137.cvx40-bradley.dialup.earthlink.net ([216.244.42.137] helo=mindspring.com) by goose.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17m2YN-0005hr-00; Mon, 02 Sep 2002 18:32:27 -0700 Message-ID: <3D7410ED.ED1D4090@mindspring.com> Date: Mon, 02 Sep 2002 18:31:25 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Wemm Cc: Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current References: <20020902215358.E3A992A893@canning.wemm.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Wemm wrote: > Matthew Dillon wrote: > > :4) Changing time_t to 64 bit using long long on a native 32 bit platform > > :is a f*cking nightmare. I've tried this and it got very nasty very quickly. > > > > This is not what I proposed. I proposed adding new system calls to > > completely and permanently fix all of our outstanding issues and then > > providing a compiler option to allow developers to select which API > > they want presented. > > Well, one thing that I would not be against is a clean divorce of the > syscall layer and libc. That then gives us the freedom to implement > alternative API selections etc at compile time pretty easily. I was really, really tempted to suggest this, but I couldn't come up with a way to make it work as a shared interface under a single libc, without doing the fixup in the crt0 ala the dlopen fixup for use of code in the ld.so (and have different crt0/ld.so's). The 32 bit versions could be stubbed to the 64's in the stub code, right there, which would make the system calls DTRT on both platforms. The other downside appears to be that the only way to do this entirely cleanly is to give up on the static linking support, so that the lib-linked-with-lib works per the ELF specification, which is a real bikeshed. 8-(. > I just really do not want to see this sort of thing turning up: > > time_t foo = time(0); > printf("the time is %lld\n", (long long)foo); /* i386 compatability */ > > .. because that hurts our 64 bit platforms down the road when long long > becomes 128 bit. intmax_t/%j etc has similar problems as it then takes > the native 64 bit time type (long) and converts it to a synthetic 128 bit > type. ie: %j and intmax_t etc are just as bad. I think the issue comes down to running 32 bit code on 64 bit platforms, particularly, Intel code, and having it "just work". I don't know how to avoid the problem, without adding sizing to the types (e.g. "time64_t"). This is a very tempting thing to do; that changes your code into: time64_t foo = time64(0); printf("the time is %lld\n", foo); Or: time_t foo = time(0); printf("the time is %ld\n", foo); /* WARNING */ I think that the argument comes down to internal use of 64 bit types on 32 bit platforms, with the 64/32 conversion done at the system call interface. PHK's right: POSIX sucks. > My first exposure to a unix OS had some pretty horrific stat structure > versioning and evilness (svr4). It was a real nightmare, except you never > got to wake up and discover that it was all over. > > I am not against providing 64 bit extentions for 32 bit systems, but it > really needs to be done so that it all becomes a giant NOP when on native > 64 bit systems. Something like the large-file-summit API extensions that > all magically go away after the transition period or when you get a chance > to do a total ABI breakaway. The real problem in the example is printf; it's because there's a sized integer type specifier in the format string, instead of an unsized one, and the compiler whines about this. That's what will end up making the code different on a 32 bit machine, no matter what. 8-(. Maybe in this case, GCC has gotten too smart for it's own good? IMO, for a long time now, POSIX has belonged in a "libposix", which is built on top of the native system services, but that's *really* a lot to ask... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 18:37:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C173F37B400 for ; Mon, 2 Sep 2002 18:37:08 -0700 (PDT) Received: from goose.mail.pas.earthlink.net (goose.mail.pas.earthlink.net [207.217.120.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D595943E7B for ; Mon, 2 Sep 2002 18:37:07 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0137.cvx40-bradley.dialup.earthlink.net ([216.244.42.137] helo=mindspring.com) by goose.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17m2cs-0003MV-00; Mon, 02 Sep 2002 18:37:06 -0700 Message-ID: <3D741204.F035A715@mindspring.com> Date: Mon, 02 Sep 2002 18:36:04 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Peter Wemm , hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current References: <20020902215358.E3A992A893@canning.wemm.org> <200209022207.g82M7OAe034138@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Well, then what we want is a new syscall vector, duplicate libraries, > and a compiler option, and leave all the function names the same > (which means no bintime but allows us to retain everything else). > -current would release supporting both with the compiler option > defaulting to --unix32 on the IA32 and --unix64 on 64 bit platforms, > and then down the line the compiler option would default to --unix64 > on all platforms, and then down the line a little more the original > syscall vector would become a compatibility option that most people > leave out. Not to be a party-pooper, but I think this will fail as soon as you have a program that wants to link against a third party library that calls entry points in libc. It doesn't even have to be a binary-only thing; think of trying to build packages for the purposes of a CDROM distribution. You would end up needing to do the same "--unix32/--unix64" thing for every library you build. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 18:48:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9073C37B400 for ; Mon, 2 Sep 2002 18:48:50 -0700 (PDT) Received: from 126.216-123-229-0.interbaun.com (126.216-123-229-0.interbaun.com [216.123.229.126]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE8F643E6E for ; Mon, 2 Sep 2002 18:48:49 -0700 (PDT) (envelope-from soralx@cydem.zp.ua) Received: from vasya ([192.168.4.251]) by 126.216-123-229-0.interbaun.com (8.11.6/8.11.6) with ESMTP id g831mch00686; Mon, 2 Sep 2002 19:48:41 -0600 (MDT) (envelope-from soralx@cydem.zp.ua) Content-Type: text/plain; charset="koi8-r" From: To: bms@spc.org Subject: Re: VMware 3 on FreeBSD? Date: Mon, 2 Sep 2002 19:48:24 -0600 X-Mailer: KMail [version 1.4] References: <20020827123054.GF68243@pcwin002.win.tue.nl> <20020902133159.GH89997@pcwin002.win.tue.nl> <20020902135406.GC2409@spc.org> In-Reply-To: <20020902135406.GC2409@spc.org> Cc: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209021948.24020.soralx@cydem.zp.ua> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Ah. I installed the vmware2 port, *then* the vmware3 rpm (using rpm2cpio). > This just used the existing vmmon module. I assume more tweaking will > be necessary as was the case for vmware2. Does vmware3 really work with 'vmmon' version2? --- VMware Workstation Error: Could not get vmmon module version: Resource temporarily unavailable. You have an incorrect version of the `vmmon' kernel module. Try reinstalling VMware Workstation. --- 02.09.2002; 19:46:04 [SorAlx] http://cydem.zp.ua/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 20:57:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB1E737B400 for ; Mon, 2 Sep 2002 20:57:24 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AF3F43E72 for ; Mon, 2 Sep 2002 20:57:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g833vNPQ040204; Mon, 2 Sep 2002 20:57:23 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g833vNdS040203; Mon, 2 Sep 2002 20:57:23 -0700 (PDT) (envelope-from dillon) Date: Mon, 2 Sep 2002 20:57:23 -0700 (PDT) From: Matthew Dillon Message-Id: <200209030357.g833vNdS040203@apollo.backplane.com> To: Terry Lambert Cc: Peter Wemm , hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current References: <20020902215358.E3A992A893@canning.wemm.org> <200209022207.g82M7OAe034138@apollo.backplane.com> <3D741204.F035A715@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :Matthew Dillon wrote: :> Well, then what we want is a new syscall vector, duplicate libraries, :> and a compiler option, and leave all the function names the same :> (which means no bintime but allows us to retain everything else). :> -current would release supporting both with the compiler option :> defaulting to --unix32 on the IA32 and --unix64 on 64 bit platforms, :> and then down the line the compiler option would default to --unix64 :> on all platforms, and then down the line a little more the original :> syscall vector would become a compatibility option that most people :> leave out. : : :Not to be a party-pooper, but I think this will fail as soon :as you have a program that wants to link against a third party :library that calls entry points in libc. : :It doesn't even have to be a binary-only thing; think of trying :to build packages for the purposes of a CDROM distribution. You :would end up needing to do the same "--unix32/--unix64" thing for :every library you build. : :-- Terry Well I figured one would just use the default for third party libraries. The idea is to get the system sources working first as well as support developers who need the feature, and worry about ports and so forth later. Ports might not be able to use 64 bit functionality under 32 bit OSs until it becomes the default under 32 bit OSs. The moment we even *attempt* to introduce changes to things ports and third part libraries use, we blow up half the ports tree. Oh, wait, we've ALREADY blown up half the ports tree. On nearly every release! Its one of the big complaints I hear about FreeBSD. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 22:24: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C231637B401 for ; Mon, 2 Sep 2002 22:23:57 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8057D43E3B for ; Mon, 2 Sep 2002 22:23:56 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g835NtHu012961 for ; Mon, 2 Sep 2002 23:23:55 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 02 Sep 2002 23:23:44 -0600 (MDT) Message-Id: <20020902.232344.21272060.imp@bsdimp.com> To: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current From: "M. Warner Losh" In-Reply-To: <200209022308.g82N896t038011@apollo.backplane.com> References: <20020902223634.6DFFD2A88D@canning.wemm.org> <200209022308.g82N896t038011@apollo.backplane.com> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <200209022308.g82N896t038011@apollo.backplane.com> Matthew Dillon writes: : Peter, you are again not reading what I'm posting carefully enough. : I said very specifically that we wouldn't be using the fractional : stuff for this case. I think that this is a worthy problem to solve. But not for 5.0. It is too late in the game to be playing games this big with the ABI. It will have to wait for 6.0, even if the problem is extremely pressing and hurting people today. It is just too late. We should be focusing on polishing/finishing the features that are already in the tree, or nearly ready to go into the tree. The scope of this proposal seems too large given that we're two or three months out from a release. If you are looking ahead to 6.0, then I think now is a good time to start since we can do the cut over just after we do the branch in a few months. This will also give us time to prototype and test things so we don't have any false starts. We may even be able to retrofit it into 5.1 or 5.2, but even if we can't that's OK. I mean, I've stalled for three years getting cardbus into a release. If we can live w/o a clear and present technology for a couple of years, we certainly can wait a little bit to solve the time problem. imho. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Sep 2 22:37:13 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99F4937B400 for ; Mon, 2 Sep 2002 22:37:11 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB7BA43E3B for ; Mon, 2 Sep 2002 22:37:10 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g835b3vV063739; Tue, 3 Sep 2002 07:37:04 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "M. Warner Losh" Cc: hackers@FreeBSD.ORG Subject: Re: 64 bit API/ABI changes proposal for -current In-Reply-To: Your message of "Mon, 02 Sep 2002 23:23:44 MDT." <20020902.232344.21272060.imp@bsdimp.com> Date: Tue, 03 Sep 2002 07:37:03 +0200 Message-ID: <63738.1031031423@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020902.232344.21272060.imp@bsdimp.com>, "M. Warner Losh" writes: >In message: <200209022308.g82N896t038011@apollo.backplane.com> >I think that this is a worthy problem to solve. But not for 5.0. [...] Good thinking. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 1:41:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B4D237B400 for ; Tue, 3 Sep 2002 01:41:37 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3DE043E4A for ; Tue, 3 Sep 2002 01:41:36 -0700 (PDT) (envelope-from bvagnoni@comcast.net) Disposition-notification-to: bvagnoni@comcast.net Received: from system1 (pcp01325377pcs.pwayne01.pa.comcast.net [68.81.19.184]) by mtaout05.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with SMTP id <0H1U0056XTEAYM@mtaout05.icomcast.net> for freebsd-hackers@freebsd.org; Tue, 03 Sep 2002 04:39:46 -0400 (EDT) Date: Tue, 03 Sep 2002 04:39:16 -0400 From: bvagnoni@comcast.net Subject: Need ER Help Setting Up My 4.6.2 Box Behind a Nated Router To: freebsd-hackers@freebsd.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dear All;; I have a 4.6.2 box connected to a Firebox 700, which is doing one to one nat. The firebox is setup to take public ip 64.220.249.197/29, gateway 64.220.249.193 and translate it to 192.168.1.103/24, gateway 192.168.1.1. I can ping the private gateway, the box itself and other computers on the network, But I can not ping anything out side of it. I have other machince none freebsd boxes on the same private network that can get out on the net fine without any problems. The interface that I'm using is called sf0 which is attached to an adpatec nic card which is connected to the firebox. The contents of my rc.conf file are as follows: defaultrouter="192.168.1.1" hostname="system3.v-system.net" ifconfig_sf0="inet 192.168.1.103 netmask 255.255.255.0" kern_securelevel_enable="NO" linux_enable="YES" moused_enable="YES" nfs_reserved_port="YES" sendmail_enable="YES" sshd_enable="YES" nfs_server_enable="YES" gateway_enable="YES" firewall_enable="YES" firewall_type="OPEN" natd_enable="YES" natd_interface="sf0" natd_flags="" sysctl net.inet.ip.forwarding=1 natd is not listed in services I took it out as it didn't seem to help helping it in there. other available interfaces are fxp0(unused intel nic card) ppp0, sl0, faith0 I don't care about a firewall as it's totally behind the firebox 700. I just want to be able to send and receiev packets to and from the internet to that box. WHat am I dong wrong. Please any help, it's 4am here and I've looked though the man, the 2 years worht of e-mails and I just can't find the answer. I wish there was a faq about this subject. It seems like a common problem SO please I have a server that is down right now if you could help I would be enternally gateful. Please please I so burnt at this point. Sincerely Brian PS I have the following options compiled in my kernel: cd /usr/src/sys/i386/conf cp GENRIC SYSTEM3 edit SYSTEM3 placed those lines in there under the other option lines options IPFIREWALL options IPDIVERT options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE save & exit cd /usr/src make buildkernel KENCONF=SYSTEM3 make installkernel KENCONF=SYSTEM3 sync reboot To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 1:43:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31D2237B400 for ; Tue, 3 Sep 2002 01:43:44 -0700 (PDT) Received: from utility.clubscholarship.com (utility.clubscholarship.com [198.78.70.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBFF543E4A for ; Tue, 3 Sep 2002 01:43:43 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Received: from localhost (root@localhost) by utility.clubscholarship.com (8.11.6/8.11.6) with ESMTP id g838ePn55308 for ; Tue, 3 Sep 2002 01:40:25 -0700 (PDT) (envelope-from root@utility.clubscholarship.com) Date: Tue, 3 Sep 2002 01:40:25 -0700 (PDT) From: Patrick Thomas To: Subject: `dump` and/or `restore` incorrectly handles /dev files Message-ID: <20020903012715.G58763-100000@utility.clubscholarship.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Try this - it's good for a laugh: ls -asl dev/*mem 0 crw-r----- 1 root kmem 2, 1 Aug 27 15:16 kmem 0 crw-r----- 1 root kmem 2, 0 Aug 27 15:16 mem Now run this command, changing some permissions: chmod -w dev/mem ; chmod -w dev/kmem Now, dump that filesystem that your /dev resides on with: `dump -0a -f /some/file /dev/ad0a` Now, restore your dump file (/some/file) with: `restore -x -f /some/file` (I just restored into some arbitrary directory) (answered "1" for which volume to start with, and answered "y" to the trailing "set owner/mode for ." question) Now, once again, ls -asl dev/*mem 0 crw------- 1 root wheel 2, 1 Sep 3 01:13 kmem 0 crw------- 1 root wheel 2, 0 Sep 3 01:13 mem ------- Gee, that's funny - not only are they _not_ -w as they were changed to before dumping, but they've also lost a ----r----- as well ! Easily reproducible. Don't respond to this thread if all you have to say is "well you shouldn't be chmodding those files -w anyway". --pt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 2:45: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 853EC37B400 for ; Tue, 3 Sep 2002 02:45:00 -0700 (PDT) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 941B943E6A for ; Tue, 3 Sep 2002 02:44:59 -0700 (PDT) (envelope-from listsub@401.cx) Received: from 401.cx (jenny.twenty4help.se [62.20.102.59]) by maile.telia.com (8.12.5/8.12.5) with ESMTP id g839ioMs029585; Tue, 3 Sep 2002 11:44:51 +0200 (CEST) X-Original-Recipient: freebsd-hackers@FreeBSD.ORG Message-ID: <3D74851D.5080407@401.cx> Date: Tue, 03 Sep 2002 11:47:09 +0200 From: "Roger 'Rocky' Vetterberg" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bvagnoni@comcast.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Need ER Help Setting Up My 4.6.2 Box Behind a Nated Router References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG bvagnoni@comcast.net wrote: > Dear All;; > > I have a 4.6.2 box connected to a Firebox 700, which is doing one to one > nat. The firebox is setup to take public ip 64.220.249.197/29, gateway > 64.220.249.193 and translate it to 192.168.1.103/24, gateway 192.168.1.1. > > I can ping the private gateway, the box itself and other computers on the > network, But I can not ping anything out side of it. I have other machince > none freebsd boxes on the same private network that can get out on the net > fine without any problems. > > The interface that I'm using is called sf0 which is attached to an adpatec > nic card which is connected to the firebox. > > The contents of my rc.conf file are as follows: > > defaultrouter="192.168.1.1" > hostname="system3.v-system.net" > ifconfig_sf0="inet 192.168.1.103 netmask 255.255.255.0" > kern_securelevel_enable="NO" > linux_enable="YES" > moused_enable="YES" > nfs_reserved_port="YES" > sendmail_enable="YES" > sshd_enable="YES" > nfs_server_enable="YES" > gateway_enable="YES" > firewall_enable="YES" > firewall_type="OPEN" > natd_enable="YES" > natd_interface="sf0" > natd_flags="" > sysctl net.inet.ip.forwarding=1 > > natd is not listed in services I took it out as it didn't seem to help > helping it in there. > > other available interfaces are fxp0(unused intel nic card) ppp0, sl0, faith0 > > I don't care about a firewall as it's totally behind the firebox 700. I just > want to be able to send and receiev packets to and from the internet to that > box. > > WHat am I dong wrong. Please any help, it's 4am here and I've looked though > the man, the 2 years worht of e-mails and I just can't find the answer. I > wish there was a faq about this subject. It seems like a common problem > > SO please I have a server that is down right now if you could help I would > be enternally gateful. Please please I so burnt at this point. > > Sincerely > > Brian > > PS I have the following options compiled in my kernel: > > cd /usr/src/sys/i386/conf > > cp GENRIC SYSTEM3 > edit SYSTEM3 > placed those lines in there under the other option lines > > > options IPFIREWALL > options IPDIVERT > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPFIREWALL_VERBOSE > > > save & exit > > cd /usr/src > > make buildkernel KENCONF=SYSTEM3 > make installkernel KENCONF=SYSTEM3 > sync > reboot > This is a guess, I currently dont have a box available to test on, but if you set natd_enable=YES and firewall_enable=YES in rc.conf, it will add a rule like "divert 8668 ip from any to any via sf0" as one of the first firewall rules. If you have that rule and no natd running, you will experience some difficulties connecting. Try something like 'ipfw flush && ipfw add 00001 allow ip from any to any' (do this at the console, not logged in over the network!). After that you can be sure your firewall and/or natd will not be causing the problems, and you can if needed continue your troubleshooting. If you still have problems, please reply to me and/or freebsd-questions@freebsd.org. freebsd-hackers is not the correct list for these kind of questions. -- R To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 3:13:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75C7E37B401 for ; Tue, 3 Sep 2002 03:13:41 -0700 (PDT) Received: from smtp1.cubecom.it (smtp1.cubecom.it [62.221.132.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC97E43E6A for ; Tue, 3 Sep 2002 03:13:39 -0700 (PDT) (envelope-from paolo@linux.netline.it) Received: from linux.netline.it ([212.13.4.2]) by smtp1.cubecom.it (8.11.1/8.11.1) with SMTP id g83ADaH09902 for ; Tue, 3 Sep 2002 12:13:38 +0200 (CEST) (envelope-from paolo@linux.netline.it) Received: (qmail 69550 invoked by uid 1006); 2 Sep 2002 16:35:24 -0000 Date: Mon, 2 Sep 2002 18:35:24 +0200 From: Paolo To: freebsd-stable@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: to log the output of rc scripts Message-ID: <20020902183524.A69527@linux.netline.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all! I need to administer remotely a bunch of freebsd boxes. I would be very useful to have access to the output of the rc scripts to see, for example, if a cvsup session has worked correctly... Is it there an option to force logging the output of the rc scripts? Would it be useful if I started working on the subject? Thanks! Paolo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 3:22:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 453F137B405 for ; Tue, 3 Sep 2002 03:22:30 -0700 (PDT) Received: from south.nanolink.com (south.nanolink.com [217.75.134.10]) by mx1.FreeBSD.org (Postfix) with SMTP id DFF9843E42 for ; Tue, 3 Sep 2002 03:22:28 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 5945 invoked by uid 85); 3 Sep 2002 10:31:01 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.131.130) by south.nanolink.com with SMTP; 3 Sep 2002 10:31:00 -0000 Received: (qmail 40302 invoked by uid 1000); 3 Sep 2002 10:21:19 -0000 Date: Tue, 3 Sep 2002 13:21:19 +0300 From: Peter Pentchev To: Paolo Cc: freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: to log the output of rc scripts Message-ID: <20020903102119.GC39422@straylight.oblivion.bg> Mail-Followup-To: Paolo , freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org References: <20020902183524.A69527@linux.netline.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z4+8/lEcDcG5Ke9S" Content-Disposition: inline In-Reply-To: <20020902183524.A69527@linux.netline.it> User-Agent: Mutt/1.5.1i X-Virus-Scanned: by Nik's Monitoring Daemon (AMaViS perl-11d ) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --z4+8/lEcDcG5Ke9S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 02, 2002 at 06:35:24PM +0200, Paolo wrote: > Hi all! > I need to administer remotely a bunch of freebsd boxes. I would > be very useful to have access to the output of the rc scripts to see, for > example, if a cvsup session has worked correctly... > Is it there an option to force logging the output of the rc scripts? > Would it be useful if I started working on the subject? I believe that, in general, 'dmesg -a' should do what you want. A quick and easy solution, off the top of my head, would be to add an /usr/local/etc/rc.d/ZZZZZZZZ.savemessages.sh script, which does something like dmesg -a > /var/log/dmesg-afterboot.log or the like. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contains exactly threee erors. --z4+8/lEcDcG5Ke9S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9dI0f7Ri2jRYZRVMRAv8XAKCDOJ+UHUjiKWZLIp23JxAvqTrmpgCfVg/Y Gv+NwueFas4oWSuUnl7n4Bc= =WBX/ -----END PGP SIGNATURE----- --z4+8/lEcDcG5Ke9S-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 6: 3:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45D7137B400; Tue, 3 Sep 2002 06:03:20 -0700 (PDT) Received: from lurza.secnetix.de (lurza.secnetix.de [212.66.1.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15D5343E65; Tue, 3 Sep 2002 06:03:19 -0700 (PDT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [IPv6:::1]) by lurza.secnetix.de (8.12.5/8.12.5) with ESMTP id g83D3GmC048102; Tue, 3 Sep 2002 15:03:17 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.5/8.12.5/Submit) id g83D3Gqp048101; Tue, 3 Sep 2002 15:03:16 +0200 (CEST) Date: Tue, 3 Sep 2002 15:03:16 +0200 (CEST) Message-Id: <200209031303.g83D3Gqp048101@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Length limit of mounts (80 chars?) User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.6-STABLE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, There seems to be a limit on the length of mounts, which is apparently 80 characters on i386 machines (and even only 64 characters on alpha machines). However, I need to be able to use NFS mounts that are longer than that. What do I have to do to increase that limit? I've searched the list archives, but haven't found a useful answer. I've also tried to change the MNAMELEN value in sys/mount.h and recompile the system, but got panics right from the start. So I guess my attempt was probably a bit naive, and I forgot something important. Any assistance would be very welcome -- thanks in advance! Regards Oliver PS: I'm using FreeBSD 4-stable. -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 Mьnchen Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "All that we see or seem is just a dream within a dream" (E. A. Poe) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 6:12:48 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3907837B400 for ; Tue, 3 Sep 2002 06:12:42 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id C15D143E4A for ; Tue, 3 Sep 2002 06:12:41 -0700 (PDT) (envelope-from bvagnoni@comcast.net) Disposition-notification-to: bvagnoni@comcast.net Received: from system1 (pcp01325377pcs.pwayne01.pa.comcast.net [68.81.19.184]) by mtaout05.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with SMTP id <0H1V006Y45YBU3@mtaout05.icomcast.net> for freebsd-hackers@FreeBSD.ORG; Tue, 03 Sep 2002 09:10:59 -0400 (EDT) Date: Tue, 03 Sep 2002 09:10:28 -0400 From: bvagnoni@comcast.net Subject: RE: Need ER Help Setting Up My 4.6.2 Box Behind a Nated Router In-reply-to: <3D74851D.5080407@401.cx> To: Roger 'Rocky' Vetterberg Cc: freebsd-hackers@FreeBSD.ORG Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dear Roger; Tried that and still no luck I can't route to the net. Here is a diagram of my network I hope that helps you or someone else with my problem: No it's not a router for other machines. It's just a machine behind a routerguard the Watch Firebox 700 that I wnat to allow to send and receive packets to and fromt he internet. internet 64.229.249.194/29 -----> 1 to 1 NAT for addresses 64.220.249.195-198 --- 192.168.1.101 - 104 firebox router 64.220.249.193 ---- >> 192.168.1.1 | | | |----------------------|--------------------------|------------| windows web server windows box freebsdbox windows box 192.168.1.101 192.168.1.102 192.168.1..103 192.168.1.104 Sincerely Brian -----Original Message----- From: owner-freebsd-hackers@FreeBSD.ORG [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Roger 'Rocky' Vetterberg Sent: Tuesday, September 03, 2002 5:47 AM To: bvagnoni@comcast.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Need ER Help Setting Up My 4.6.2 Box Behind a Nated Router bvagnoni@comcast.net wrote: > Dear All;; > > I have a 4.6.2 box connected to a Firebox 700, which is doing one to one > nat. The firebox is setup to take public ip 64.220.249.197/29, gateway > 64.220.249.193 and translate it to 192.168.1.103/24, gateway 192.168.1.1. > > I can ping the private gateway, the box itself and other computers on the > network, But I can not ping anything out side of it. I have other machince > none freebsd boxes on the same private network that can get out on the net > fine without any problems. > > The interface that I'm using is called sf0 which is attached to an adpatec > nic card which is connected to the firebox. > > The contents of my rc.conf file are as follows: > > defaultrouter="192.168.1.1" > hostname="system3.v-system.net" > ifconfig_sf0="inet 192.168.1.103 netmask 255.255.255.0" > kern_securelevel_enable="NO" > linux_enable="YES" > moused_enable="YES" > nfs_reserved_port="YES" > sendmail_enable="YES" > sshd_enable="YES" > nfs_server_enable="YES" > gateway_enable="YES" > firewall_enable="YES" > firewall_type="OPEN" > natd_enable="YES" > natd_interface="sf0" > natd_flags="" > sysctl net.inet.ip.forwarding=1 > > natd is not listed in services I took it out as it didn't seem to help > helping it in there. > > other available interfaces are fxp0(unused intel nic card) ppp0, sl0, faith0 > > I don't care about a firewall as it's totally behind the firebox 700. I just > want to be able to send and receiev packets to and from the internet to that > box. > > WHat am I dong wrong. Please any help, it's 4am here and I've looked though > the man, the 2 years worht of e-mails and I just can't find the answer. I > wish there was a faq about this subject. It seems like a common problem > > SO please I have a server that is down right now if you could help I would > be enternally gateful. Please please I so burnt at this point. > > Sincerely > > Brian > > PS I have the following options compiled in my kernel: > > cd /usr/src/sys/i386/conf > > cp GENRIC SYSTEM3 > edit SYSTEM3 > placed those lines in there under the other option lines > > > options IPFIREWALL > options IPDIVERT > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPFIREWALL_VERBOSE > > > save & exit > > cd /usr/src > > make buildkernel KENCONF=SYSTEM3 > make installkernel KENCONF=SYSTEM3 > sync > reboot > This is a guess, I currently dont have a box available to test on, but if you set natd_enable=YES and firewall_enable=YES in rc.conf, it will add a rule like "divert 8668 ip from any to any via sf0" as one of the first firewall rules. If you have that rule and no natd running, you will experience some difficulties connecting. Try something like 'ipfw flush && ipfw add 00001 allow ip from any to any' (do this at the console, not logged in over the network!). After that you can be sure your firewall and/or natd will not be causing the problems, and you can if needed continue your troubleshooting. If you still have problems, please reply to me and/or freebsd-questions@freebsd.org. freebsd-hackers is not the correct list for these kind of questions. -- R To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 7:19:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD43037B400 for ; Tue, 3 Sep 2002 07:19:50 -0700 (PDT) Received: from edgemaster.zombie.org (edgemaster.creighton.edu [147.134.112.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C49043E6A for ; Tue, 3 Sep 2002 07:19:48 -0700 (PDT) (envelope-from smkelly@zombie.org) Received: by edgemaster.zombie.org (Postfix, from userid 1001) id 2820B66B04; Tue, 3 Sep 2002 09:19:47 -0500 (CDT) Date: Tue, 3 Sep 2002 09:19:47 -0500 From: Sean Kelly To: Peter Pentchev Cc: Paolo , freebsd-hackers@freebsd.org Subject: Re: to log the output of rc scripts Message-ID: <20020903141946.GA49976@edgemaster.zombie.org> References: <20020902183524.A69527@linux.netline.it> <20020903102119.GC39422@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020903102119.GC39422@straylight.oblivion.bg> User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 03, 2002 at 01:21:19PM +0300, Peter Pentchev wrote: > On Mon, Sep 02, 2002 at 06:35:24PM +0200, Paolo wrote: > > Hi all! > > I need to administer remotely a bunch of freebsd boxes. I would > > be very useful to have access to the output of the rc scripts to see, for > > example, if a cvsup session has worked correctly... > > Is it there an option to force logging the output of the rc scripts? > > Would it be useful if I started working on the subject? > > I believe that, in general, 'dmesg -a' should do what you want. A quick > and easy solution, off the top of my head, would be to add an > /usr/local/etc/rc.d/ZZZZZZZZ.savemessages.sh script, which does > something like dmesg -a > /var/log/dmesg-afterboot.log or the like. Actually, I think a nice feature of rcNG is being overlooked here. At work, I deal with HP-UX machines (*ducks). When we write rc scripts for them, we have to have four argument cases in the script: * start - Run the actual command. * stop - Stops the daemon/process/whatever * start_msg - Outputs a single line description * stop_msg - Outputs a single line description For example: case $1 in start_msg) echo "Start print spooler" ;; stop_msg) echo "Stop print spooler" ;; 'start') ... ;; 'stop') ... ;; The end result of this is an /etc/rc.log generated by the rc scripts during boot which looks something like this: Start print spooler Output from "/sbin/rc2.d/S720lp start": ---------------------------- scheduler is running line printer scheduler started Start clock daemon Output from "/sbin/rc2.d/S730cron start": ---------------------------- cron started Basically, rc.log consists of the (start|stop)_msg line, followed by the name of the script that generated it, and then stdout/stderr of the actual process run by the (start|stop) case. In the end, you end up with an /etc/rc.log that shows the progress of your entire boot, and is finished with: ************************************************** HP-UX run-level transition completed Fri Aug 30 20:11:56 CDT 2002 ************************************************** I'm not saying rcNG should have a (start|stop)_msg thing, but I would like to see it log the output of stuff that it runs when booting and changing runlevels. -- Sean Kelly | PGP KeyID: 77042C7B smkelly@zombie.org | http://www.zombie.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 12:30:46 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC98A37B400 for ; Tue, 3 Sep 2002 12:30:43 -0700 (PDT) Received: from hotmail.com (f112.law14.hotmail.com [64.4.21.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id B966743E3B for ; Tue, 3 Sep 2002 12:30:43 -0700 (PDT) (envelope-from robert_fenech@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Sep 2002 12:30:43 -0700 Received: from 141.210.178.178 by lw14fd.law14.hotmail.msn.com with HTTP; Tue, 03 Sep 2002 19:30:43 GMT X-Originating-IP: [141.210.178.178] From: "Robert Fenech" To: hackers@FreeBSD.ORG Date: Tue, 03 Sep 2002 21:30:43 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Sep 2002 19:30:43.0676 (UTC) FILETIME=[651799C0:01C25380] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I've been desperately looking for some help regarding the DP83820. Is anyone willing to help me pls? Thanks. _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 12:42:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6971537B400 for ; Tue, 3 Sep 2002 12:42:38 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id A035243E42 for ; Tue, 3 Sep 2002 12:42:37 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 15646 invoked by uid 1031); 3 Sep 2002 19:41:00 -0000 Date: Tue, 3 Sep 2002 20:41:00 +0100 From: Bruce M Simpson To: Robert Fenech Cc: hackers@FreeBSD.ORG Subject: NS DP83820 gigabit MAC Message-ID: <20020903194059.GN2409@spc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Sep 03, 2002 at 09:30:43PM +0200, Robert Fenech wrote: > I've been desperately looking for some help regarding the DP83820. Is > anyone willing to help me pls? NetBSD would seem to have a driver for this. http://www.tac.eu.org/cgi-bin/man-cgi?gsip+4 AUTHORS The gsip driver was written by Jason R. Thorpe . BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 14:49:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3D4D37B400; Tue, 3 Sep 2002 14:49:19 -0700 (PDT) Received: from dmlb.org (pc1-cmbg2-6-cust106.cam.cable.ntl.com [80.4.4.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 480FC43E72; Tue, 3 Sep 2002 14:49:19 -0700 (PDT) (envelope-from dmlb@dmlb.org) Received: from slave.my.domain ([192.168.200.39]) by dmlb.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 17mLXy-000B8T-00; Tue, 03 Sep 2002 22:49:18 +0100 Received: from dmlb by slave.my.domain with local (Exim 3.36 #1) id 17mLXx-000E6o-00; Tue, 03 Sep 2002 22:49:17 +0100 Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 03 Sep 2002 22:49:17 +0100 (BST) From: Duncan Barclay To: hackers@freebsd.org, current@freebsd.org Subject: TIOCSCTTY not implemented in linuxulator? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi Does anyone know why TIOCSCTTY isn't implemented in compat/linux_ioctl.c? The last change in this area was back in 1999 when the ioctl handling was revamped, but this ioctl was not implemented. Do controlling terminals work okay in the linuxulator? Implementing this might solve a problem with Matlab, where it refuses to exit. Matlab issues calls to two unimplemented ioctls on the tty side of a pty/tty pair. linux: 'ioctl' fd=4, cmd=0x1 ('',1) not implemented linux: 'ioctl' fd=4, cmd=0x1 ('',1) not implemented linux: 'ioctl' fd=4, cmd=0x540e ('T',14) not implemented 0x540e is TIOCSCTTY, and according to /compat/linux/usr/include/asm/ioctls.h 0x1 is TIOCSER_TEMT (Transmitter physically empty)? I'm using 4.6-PRERELEASE linux_base-6.1_1 linux_devtools-6.1 linux_kdump-1.4 Thanks Duncan -- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@dmlb.org | the alcoholics, and the permanently stoned. dmlb@freebsd.org| Steven King To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 15: 6:47 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4799D37B400 for ; Tue, 3 Sep 2002 15:06:43 -0700 (PDT) Received: from host213-120-100-207.in-addr.btopenworld.com (host213-120-100-207.in-addr.btopenworld.com [213.120.100.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id C183243E42 for ; Tue, 3 Sep 2002 15:06:42 -0700 (PDT) (envelope-from dom@host213-120-100-207.in-addr.btopenworld.com) Received: by host213-120-100-207.in-addr.btopenworld.com (Postfix, from userid 1001) id 200C225B; Tue, 3 Sep 2002 23:06:56 +0100 (BST) Date: Tue, 3 Sep 2002 23:06:55 +0100 From: Dominic Marks To: freebsd-hackers@freebsd.org Subject: network interface lock order reversal question Message-ID: <20020903220655.GA1545@gallium> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hey, Just put -CURRENT back on an AMD Athlon machine I have after a three or four month absense, looking through dmesg I see the following: vr0: port 0xd400-0xd4ff mem 0xd8000000-0xd80000ff irq 11 at device 9.0 on pci0 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 lock order reversal 1st 0xc2667a90 vr0 (network driver) @ /usr/src/sys/pci/if_vr.c:659 2nd 0xc0488140 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:317 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 /usr/src/sys/vm/uma_core.c:1332: could sleep with "vr0" locked from /usr/src/sys/pci/if_vr.c:659 >> /usr/src/sys/pci/if_vr.c ~ 659 (vr_attach) mtx_init(&sc->vr_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK, MTX_DEF | MTX_RECURSE); VR_LOCK(sc); << >> /usr/src/sys/pci/if_vrreg.h ~ 468 #define VR_LOCK(_sc) mtx_lock(&(_sc)->vr_mtx) << >> /usr/src/sys/vm/uma_core.c ~ 1332 (uma_zalloc_arg) if (!(flags & M_NOWAIT)) { KASSERT(curthread->td_intr_nesting_level == 0, ("malloc(M_WAITOK) in interrupt context")); WITNESS_SLEEP(1, NULL); } << >> /usr/src/sys/sys/lock.h ~ 233 #define WITNESS_SLEEP(check, lock) \ witness_sleep((check), (lock), __FILE__, __LINE__) << The solution, if I understand correctly is to drop the lock before entering the UMA code. The call of contigmalloc() in the vr driver is, I guess the route into the UMA code (via the vm ?), so would dropping the lock around the call to contigmalloc() be a solution, or am I missing the big picture? RFC? -- Dominic Marks Computer & Politics Geek [work]::[npl.co.uk] << dominic.marks at npl.co.uk >> [educ]::[umist.ac.uk] << notyet-known at umist.ac.uk >> [home]::[btinternet] << dominic_marks at btinternet.com >> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 15:53:24 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E740337B400; Tue, 3 Sep 2002 15:53:20 -0700 (PDT) Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1578943E42; Tue, 3 Sep 2002 15:53:20 -0700 (PDT) (envelope-from pavan.balaji@intel.com) Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.43 2002/08/30 20:06:11 dmccart Exp $) with SMTP id g83MrIP08441; Tue, 3 Sep 2002 22:53:18 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002090315522612103 ; Tue, 03 Sep 2002 15:52:26 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Sep 2002 15:53:17 -0700 Message-ID: <3D386AED1B47D411A94300508B11F18704AD69DD@fmsmsx116.fm.intel.com> From: "Balaji, Pavan" To: "'freebsd-questions@freebsd.org'" Cc: "'freebsd-hackers@freebsd.org'" Subject: Copy from Virtual address space to Physical address space Date: Tue, 3 Sep 2002 15:53:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, The copy from the virtual address space to the physical address space problem has been solved. I have mapped two pages (one user virtual address and another kernel virtual address) to the same physical address, to get rid of this problem. Thanx to everyone who came in with information/help regarding the same. Pavan Balaji, Intel Corporation Email: pavan.balaji@intel.com "Only the Paranoid Survive" -- Andy Grove To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 17:17:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1464537B400; Tue, 3 Sep 2002 17:17:25 -0700 (PDT) Received: from starbug.ugh.net.au (starbug.ugh.net.au [203.31.238.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F76E43E6E; Tue, 3 Sep 2002 17:17:24 -0700 (PDT) (envelope-from andrew@ugh.net.au) Received: by starbug.ugh.net.au (Postfix, from userid 1000) id 16988A804; Wed, 4 Sep 2002 10:17:23 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by starbug.ugh.net.au (Postfix) with ESMTP id 0C9BB5425; Wed, 4 Sep 2002 10:17:23 +1000 (EST) Date: Wed, 4 Sep 2002 10:17:22 +1000 (EST) From: Andrew To: Paolo Cc: freebsd-stable@freebsd.org, Subject: Re: to log the output of rc scripts In-Reply-To: <20020902183524.A69527@linux.netline.it> Message-ID: <20020904101647.H69130-100000@starbug.ugh.net.au> X-WonK: *wibble* MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 2 Sep 2002, Paolo wrote: > be very useful to have access to the output of the rc scripts to see, for > example, if a cvsup session has worked correctly... Have you tried enabling console .log in syslog.conf? Does that do what you want? Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 17:57: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91BD237B400 for ; Tue, 3 Sep 2002 17:57:02 -0700 (PDT) Received: from out011.verizon.net (out011pub.verizon.net [206.46.170.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id E091543E3B for ; Tue, 3 Sep 2002 17:57:01 -0700 (PDT) (envelope-from arlankfo@verizon.net) Received: from verizon.net ([138.88.7.120]) by out011.verizon.net (InterMail vM.5.01.05.09 201-253-122-126-109-20020611) with ESMTP id <20020904005701.FCBF17563.out011.verizon.net@verizon.net> for ; Tue, 3 Sep 2002 19:57:01 -0500 To: hackers@freebsd.org Subject: Re: 64 bit API/ABI changes proposal for -current From: "Andrew Lankford" Reply-To: "Andrew Lankford" Date: Tue, 03 Sep 2002 20:57:04 -0400 Message-Id: <20020904005701.FCBF17563.out011.verizon.net@verizon.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At the risk of butting into an important thread and revealing my total ignorance about all this stuff, I notice that NetBSD claims to be "64 bit clean" since "1.0", right down to FFS (I looked around the NetBSD mailing lists recently for discussions about UFS2--there didn't appear to be much interest in their camp for it, kind of odd I thought) . So does that mean they had to make big changes to their system call interface/ABI? If so, would their experiences/approach be of any use to FreeBSD? Andrew Lankford To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Sep 3 21:35:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2234C37B400 for ; Tue, 3 Sep 2002 21:35:31 -0700 (PDT) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CDF143E42 for ; Tue, 3 Sep 2002 21:35:30 -0700 (PDT) (envelope-from lindaroberts314@yahoo.com) Received: from washdc3-ar1-4-40-132-235.washdc3.elnk.dsl.genuity.net ([4.40.132.235] helo=MIKULAFX390) by flamingo.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17mR6u-00023T-00 for freebsd-hackers@freebsd.org; Tue, 03 Sep 2002 20:45:44 -0700 From: "Linda Roberts" Subject: I thought you'd find this interesting.... To: freebsd-hackers@freebsd.org Content-Type: text/html;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Reply-To: lindaroberts314@yahoo.com Date: Tue, 3 Sep 2002 23:45:44 -0400 X-Priority: 3 X-Library: Indy 8.0.25 Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG

           Want To Get A Lot Of Target Email  Addresses Right Now?

We can help you!    Our services were developed for enterprises, small businesses, and individuals to find email addresses of the customers who are in deadly need of your products.

By using the most advanced Targeting Email Extractors we    are  able  to provide you with lists of thousands of valid emails.

What you need to do is just provide some keywords, such as 'apartment' for a real estate developer, and we will find thousands of emails relevant to your keywords.

As an added bonus, if you act within the next 48 hrs, we will give you a FREE Bulk Email Sender so that you will be all set to email your thousands of targeted clients or customers with YOUR message.

Please, act today. If for any reason you are not satisfied, we will provide a full refund, and the Bulk Email Sender is yours to keep.


5000 targeted emails for just $14.99

CLICK HERE TO ORDER
Disclaimer:
We are strongly against continuously sending unsolicited emails to those who do not wish to receive our special mailings. We have attained the services of an independent 3rd party to overlook list management and removal services. This is not unsolicited email. If you do not wish to receive further mailings, please click this link http://www.autoemailremoval.com/cgi-bin/remove.pl . Auto Email Removal Company. Ref# 01222263545
This message is a commercial advertisement. It is compliant with all federal and state laws regarding email messages including the California Business and Professions Code.

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 4 7: 9:42 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 514B737B400 for ; Wed, 4 Sep 2002 07:09:34 -0700 (PDT) Received: from ksue.kharkov.ukrtel.net (ksue.kharkov.ukrtel.net [195.5.57.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C2FD43E7B for ; Wed, 4 Sep 2002 07:09:29 -0700 (PDT) (envelope-from hw@ksue.edu.ua) Received: from LONELYPC.TECIS (lonelypc.local [192.168.0.3]) by mirinda.local (8.11.6/8.11.6) with ESMTP id g849bbR21032 for ; Wed, 4 Sep 2002 12:37:39 +0300 (EEST) (envelope-from hw@ksue.edu.ua) Date: Wed, 4 Sep 2002 12:36:26 +0300 From: Hard Wisdom , Kharkov@FreeBSD.ORG, State@FreeBSD.ORG, University@FreeBSD.ORG, of@FreeBSD.ORG, Economics@FreeBSD.ORG X-Mailer: The Bat! (v1.53d) Reply-To: Hard Wisdom , Kharkov@FreeBSD.ORG, State@FreeBSD.ORG, University@FreeBSD.ORG, of@FreeBSD.ORG, Economics@FreeBSD.ORG Organization: KSUE X-Priority: 3 (Normal) Message-ID: <13213006484.20020904123626@ksue.edu.ua> To: to Somebody it may concern Subject: [PATCH] Small contribution to FreeBSD Firewall configuration MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------110115E3E248818" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------------110115E3E248818 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello freebsd-hackers, After some attempts to configure firewall (during last 2 years) I realized necessity to automate the task. So, output of my work is here: These scripts may be easely extended to implement another security model. I think, these must be placed at /usr/share/examples/ipfw, then user may wish to install them at /etc/firewall manually and invoke as: firewall_enable="YES" firewall_type="/etc/firewall/mirinda.load" Currently configured template file is for my particular computer (configuration is somewhat complicated, but shows all configuration possibilities implemented). I use only /bin/sh utility to produce necessary loadable configuration (and make utility too, but it doesn't matter now) -- Best regards, hw mailto:hw@ksue.edu.ua ------------110115E3E248818 Content-Type: application/x-compressed; name="ipfw_reload.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw_reload.tgz" H4sIAEjRdT0AA+08aXfbyJHzVfwVbYkJLUWiCICHNFpl1yM7L/N2nPj5SD7YHg4ENkVEJMDBYUnj 8X9PVXU3boAAJcreDdszEoSuqq6urq6jD0xtj9+Y83nXchcL1/luE0Xr9Ya9HvuOYcn+Zmw40geM jQaGofWHxqjPmKYbmvEd622Em0wJ/cD0GPvOc92gCu5mxvn8MRh63LL35PjSdo79Wau1x46Ojthr Pp1zK7Bdh5nOhC14YLKpadlzO7C5jyA1iyT4cAXo/WT7AXOn7JM5D4EZevJs83IOf/hLbtlTm0/Y 5R3rLD0+tW87LYAczwHr6T773EJt83nAfmdXHl+yn9saPPqAsesf//z+5/OPB+fHx7utL5tk3TEX dTn36nF+3j3YGNfPlksOWtDxA892rjo+C1wWzHiC5Y7qRwf4WZqeGQAgswN2YwczgDMtfgiEwMS4 N2wSLue2ZQaAJ4awNeHTdC/nrmXOSUpn9PO8rZ0xf2ZPA6rmgMfaVPFh90Obnlj74MO33v+J63SC lVLQ6opBVBP2mZAJPZ9LiSRgLu/GUHUW/wU8LloEMHU99YLZDkiR3k7c1o6sQbpYQbRbO1iDEO9Z W1ae0xMR+Mj++EdmuQ50P+RMR2hH8IFFcLcrKEVIu7JBCZgaWwG6qXF9DnPMgalnep55d8jsLu+y axtGGiYmDgS7DAM2McH22QFf+MwyHXbJE2Pqd7tdGjaikBk2n6MJdb2z6Kn+8CkMgrOnIOyj3+QI sI9nqHxOa0dA94TU5j5Xb37ht0tPQf+Jab+IcbYT4v2sGvhy3v5MgF8Ka8eqFsdiY/NLjYOaRErC 0eyS1nDc8cMpPpBTstw5cukLYwpkAveKg2Q80FY5QSOCkT3FwVqYy/WGqnAiCu2VU5dFI5eRIiKV ipgqYV4cbEi+L5xwwcEmoarP58pv2o5vTzgpegumOtQU2WDTu8K3UkHlX6iiaQEI4PEZmZMx2QsJ G5kT0fGDeLY/fl+DG5f667PQRwMNSof217qzwAMnhVAuCC0tCS0lihy0nobWc9ArhKcp6SkTKkEV bApYj6CUjVYij83wVxI8zQ2ctEvPnYQWZ0vT9kji8N9m1a5KYrE3+3YlFTr2r2GBwLJRwmNLDPz/ mD0B3w8A5Pa/GRGSM1azeaOeWcBBxMBvz8QvcMdpMd/MbPA/ICyqZkfwh/Ljacs4Pk87BYL/Ipsf Y9PjyIaqxqSnF6QjTy/F3iD/m6r8H/zYZrL/lfl/fzDsU/7fHw700UiD/F8b9fVt/v8YJZf/vwmX yzlfcAfEcsc8NwwoQLty4QdEWLz2hN7E5H9petdsYfq/hpBoTSjRmmIw3qJf40k02yFqdthu29gV BioO0jTW1jdjmN5Q0HrH+G3APYeMAzwgX2wCk8wK5neSTR6xGfFlTyGfAu52dvZYlMClanlRLcSz mCSMHdExrKcmcgAmAXw2/vCH44MvAGVOJl4OaEFABlIBGV/LDIQEywQP8IAgfYCY2J+4F2xWlCTB SlHa64jS/gZEaT+SKKlR6ilDQwfx79RzF6zDO+Ti88rqUwgigGwCQipqIMC/yMkWCV7kqDjbtF12 ZFK6+lnb2+MHX1TCKrvOVQ7A52VIdg7JjpEwz+XWzGU/OuAMbcgOCaQjunfEIFHVPuyC37y1A6ap 1HcjYiVDJGwPMGviag8EI5cQs+GiHEo2ZaWe0gKDTFtbe1ElJqhLzj1/v4WvQKbRkoJ4j53fAPsX rjO1r0JcrHKdxEokMu5zK/Ts4I4t3AmfH7Ir7nDPtphvzcAtfI9rWdy5G9vOYdxHfihegrc4hHjV 96Ea/+iyZ/OFC9OOm9aMeSF0d2Ziwm4HHR/kEaJeLUEtD5kPw8pm7pLD8IFUfZgTDFq0rv1ItiQu yO8nPJBidD2MkiHDn9hWQNXc81wvigcdDnkfjJTvToMbE4Dn5h33uijSzty96jDo778gAmCdDvMh WnPAsrCJ5y4ptoQOXLk4fEvTuuZq6kRzQRJvWVKYfAwkrwD+nOjjkqEVdEiMMMV9IWFBik1xHfAS CHBQ9IJJmCCK+OeC2EZsbRBeioEHQ2ajPgAjSzMA2dNqZ1odkIO3M+ijD+nKNSivveT+IYM0JZSW A8bRdRLs+zwIxaILTcTnoCbQT8tdJAWLgUUCRypYjPXMoUkFQ0jTCbnNDU6GhgRP00DCKzGVJpcw fZzDV+NYOHxETUJIil875kuWKP6f25ceRHybaGNF/G8YQyOK/4ejIe7/9Ufb+P9RSi7+/0nogbCz YApoQVZpSRPrsxljxZdLnHppl+WEi0uOGzQMd7HBCvmt6Q1Ynl/Pe2dMPI19QD3XehvZJLIsvgwY WTpyQpG4JDuCm2CMewmpgFV4eqidu+YEff1mNrEEf6EzcQvZk+EJuud9ZBUcwSpWAYS1hWSjhV21 h4VAoSN6JEA2FYPZDvPvIFG1AoxPZuGV6bUupFUB5hNSZ7t7DBfZPXgsr23REBZUUyX6uhhXCYnt 0nuEIC9YACDeIwRFPAUQ4j1CiFwgDyHfO2YwEawuubewCwDle4QxxbjnQOR7AqENyQIQeo8QGM0V 9hrfEyfkVAsg6D31CQOqIgB8TyQ8jpvbeQjxXgzcvyDmK4Kg9wgSOh6FmVkQ9Z5akmFBDmh6I+W6 qT0uCJYd84oWVshmXXluSKYsOxv9FlWxTIL1G6aLYuGQ9gClmkvzptYD5ZT8k3ois/dLIn+S4O1k ekTtjS/vlNZLYwkwmzgHQeYDjM47YSJIFphi0H44NB5yByOoxTVZGuQpsZwbGSDKAz+0xwgnjE0M SYl+bIQIFGJXyBoI42u73G+qRPEfhfebaaM6/tP68E/Ff8Zo1MP4TzOG2/jvMUou/ksvDTRf9k3O 9Xe4GII5pL1YznFBT3gxtHodMVc7eL4C2gIjQCsg44mb3d2iVZYz8atws8ZaLCZn9LOwGhX7jH5m qiO7qkdLTnI1b6eN1GgNgFJ+sLzQCxPc2SfbZG2xptZGkpFllagEh7+XrhcoOoG1lHQOlNUupCOs sRSD0VQM6/STnHjUTewg8A+9bdhNIhP3ErK5CjKJJbn3r8HcgwGafLy3YxE+EyzNGSvslBq8uduT sDrCUoyShdX0UbeH/45PJKwRwdqykwkYSV716YIO0t67R1GfBtj2Beu8f/IRJifGichv4JnTKUS9 eExznlw56qijXZEnpEXtDhE7a+1YEYki8eBeIxA7IyJ1YN0wEMAdGUewYYLfNwFEeP7Sdac458t5 jXa25ep9p7VD0p67V3HzH9q4sD6GRlNMYPfG7XHMtuJEcPHfH9lzsEDuIpX3JGycYCKzYNVSo/kD TK5r9qNc+7nHqCZ5MjUpmtd/udBOtRNcSvRRPHhyqWA1sHBMP/FiMclR6kXqGRmcSFZnFXjaSO9q Q0LV9CZ4p4h3IhCHWbz8uFwqGUxAk4MjiHwdEPDRxA/No57RDW4D9lSDHO8OJ2pvX4joqe1Y83AC Pun1izcvXv/jxfMj7bCjYmEg+/yvF6+YGQbuUWqMD9nfXrw9evvizdtD9vLdT29/vHj25i17as3R VDzfPxSnyuivF/tJenJMQMtpPTkakkcdkeFpVx/0SyRbPSK9Lvx/rPebtKfrfclpvxGfer9XgZfX AAs04Lmyv7klYaLsuEFuvb1kNtjFskcK1YajxG5MVnMH3MwpvsFGHmjaRvyayFodRoWBS6k7JVXY hFosz/KftXlywT2yekDwZbS3cx9XlmSUg0Tfa8fGx5i24o+WGyBWpD2vbrfLPDDCnlMiwPGERChW RLICbCa8KfKk1+PJduzAhiy1iqsoK0/mrGInT4W3CZ5kF8C6YGJaxN9VUgsz21DiXKOr1HAGWFez WA9xqzbHamK6VOjiKk+bdPpJN/l3uTPyUG5S36CbzFjjoo4WGruMf6yPl/aPxXgFblL/j3GTa49I 2j82GpGEf6yNl/GP9fHS/rGuBlh6wgTk9h6ly7ifk8z6nkXefObi/KTzyW+Ux3u1Ym8hsbeMR8q4 v591QRKllXbC+sf/Ovpz2goW78qXuODIPnZalAa30/vq7JyJnfXoasUeexlaMzbj5iebe+CHRD06 1afA4qU9yW37FjS730Tv0y6/MERJSB/S58buPxKZzBoL3T8ARf7/FU7xZ8IB3iuTTXL6BBLCVyo3 V/mrEqJwYmhfmhn2wmR/dQzwjShDmvv6SkBr+ZnceT2qlbpVOWL5w3n5fD42OgU8qQAj+iM7XDRe 62CmOlVqBysI64NBN/F/eSiplrGA7psgnE7vuezTZGLnT50UTmsJlh7YKfgUuSuccCTxcS4hksAL 6ZIMxa8lglwj6pXbj7ZTFvRy4O69gUE5KV+Rz1PBOZKv4q9uVG6khjfJ2H16baRnb2mQn/LwdI8t 59uuHffGqRyJyLm0cwfS6kb2xUkSsnb8k/RYOGn4JJ1H0j5uUUCBq6Jfe4NjWypLtP+3ND2fb6aN Fee/2Eg35PcfhsZooNH+X2/7/YdHKdn9v4crrS475oF1rDQsepCfGsGz8WKvhM1N5yo0r/CIOvjQ ckR5RhEQ/6KW8vGMGlo4WVWOi/ebsEk6jUG5iDg7hnlrwBfLuRnwHDbeE9jJHJcub4K20BH+jToz GxF+cOHK4xHsz239jEVnIOBPo5nFjZhXrG5Ax1ad/9S1+PwnWAGc/0N9O/8fpazY/8czgetc/jra zPnPf+KRfhn2RYu1cluxKPu3zNDn7IauZeBnAmZ8wS4hwjrE1VGMUGaue50OtjAFpS98cAijaHXf tIIQGrhDAp7p+As7oCMM+HmILntH18nxejmdzZuYfIGmhS44LF3ft8WlBUBGVhAuYhQM17WPhyPC eWByN/TndyLCt6dTELYTMGtuwy+/K67cxCnX9HaJx2SiJUUNF75QKBIQmhj7eIJvuRSAgy78G3VH o2NDzwJOTTwudbvU2EmvCyRxfeukd6yfCEBxgs0EHsXSDbMpAqeQUbVD1zdu5OAkFn9UpJ68QiT7 hHUoEWodj+jNxfcaUtI5pO9w+Nz7xPEaEl0EQaQImm4cYEdTaN3CewDq6F/cy+EgccaDsuRIHqk9 /QfUYUpY4oEzGJ6Ic/j87tVFtq7P8Izrrb3IVgyg4u+eac15K1ul9TSofMWXvo1bFi5uDOABC7wZ fM3v8N1TmDr2ZH8jJ3J/cG9Rcv/75t0LUIdLNXLZThtiexKVUutqJ/oqAAOPfj97gS9fuRPTgzl7 MTODNJrR1TRN7EN2tVOte6J1T3tlIL3TrjYAcRm9rq5VAOn90+6wD782chbyby506+UPz9CERQqs VnBbE5cyeLwUJg7KnpXk9nRSSELHx3ASpzU0Y7Si/mRF/WlUH06q6RfXn6yoP/3GrsX8x5SFeQ0B 8XxDmZ8oGP/1+6Xxn96T93+ModbvYyyo9UbDwTb+e4zysEYNbBp7FgbuwqQbGZwCJR/ctTzhDSEl fjdrjzUqTy/2mX5y9Cy8OtJ7Pf0OP5N38Nd/HrT2Wi17Ob3ZOd859jGKxT/Y0a+tS9Pn+DKZprWs 6c6T852Z6wfiurD/0Ba95fHIPn+/0/5sTb90MSnrOvzmwdtKk1fNifajg27dg9bOjh9f3xKLPCwF +wFA8iJPk5d/ihxTdCdJ4/udXBYJRNGPZF+z9v88uCQgNLhzrJnnOvZviTN+GBlSEK60EIYH2f8e WGt/Rk35QreYhv0e5KbivkvR+uXOznt25KUkQBKi70ooQu3PqHJfjnNQv/+eJhBJVBJYfMpXxC8K CMRjkCGQqEhxUcSBHOSKLiBUQlDy9gTJauun/z+Vhe3ZzsSUM3kzbTRb/xng+k9vtPX/j1K26z/b 9Z/t+s92/ecBurZd/2kqr+36z3b95ysXFf9hwL+pNqrXf3RNB+cl4z9IMHT8/uNgpG3jv8comALD +Ky+NImAOgCuvDGJgIYCrLguucdq3mgkigOtx6qvI1JMZDtNoPHIK4Hrq8ApjlLE60FHxI0avGgR 8XrQSFwIcMUVSyI6VMNRciNBy5ybT/a2KW6yM2W4qWi0ZAjXwF3Rbja6bdRwBbKSFozHysumCNT0 9qfgSi/iKnezUPGzGid9j6UBXv6eZz3ENJM4XOswWRMvzyQhgvQf7t4pJkYPcI8GyJRdnxEdNdYY +SqcgvukNRGTF2bqoyXvyzTAStyWqY9VpmQN5VETMSuPemhZedTEyshD6fO6t2hbcvG7oEWErzTw ytw9wB1ZwcagouOCm8js5x3UKuSk6U65ishgN7s8i3jN77IKXkc9lvySV16jKvq5Areqm+tccxWN npQ0mlzCKIt8aiD374M8uA8yrpTURY9y4oo1jAehYqxBpXDd4150Uosj96UUr6CsNUxGxvRoa2tX U+TBfZAz2lWJXlu77kvFWINKuXatSyevXfeglNGuZG50z6vzgpnTNRKnqCcNkZPMN736Tg2OCjOX OCTKMFqBk467G+CVXnJfgVjIZBQYNWRyFV4pk1GO8GCX7h8pRxhpa4x8IU75ZfpViMlguD5aMhhu gJUIhutjrVCyhvJYhVgijxVoJfJYhVUsjyhHWOsTAqK9qjS7IFFIra1FAfY6HwgQzUNKhJ9mLd6z S4W88bLiw301QPBQkSTF4XqZFyjHLuA+5wfWud1PC4Nr37UXTA9LVoSrEpRSpNLMpBirllRzWHWk 2fQ+u2hqlGcw68LLJoHq4z1IRD2uQaPo2noiXW9+o1y0jBEZ7kCWbS3WADqpA3SaBirbaawBdFIH 6JQy4+Y34QVtCO7kRfYaWUusCZVoWeNdEy2bqdREy+coRYhNspM18Y1G+JUZSUMKhblIcxr5LERN ubU+ZUCNn5RtyiW1LGuCayD110EarIOE+lWKlhBorEbp3lV0rwDbWAM7pUEJdDG4NfDT+rMmhYT2 1KewSiuSLra2VjREGqyDpLSiEK22VtTFLtaKauzVWrECv4ZWrKawSisait3IRxRN1KIR1mAtrIRi FOA10Yx66KWqUYVeSzcqCdRTjlUkamhHlII1/LyMaFWlmfXWraS7q/hSjKCq97Yfi/m2ijr/JW6L bKaNFff/WN/Inv/anv9/rCJv9sAQteSjHj8a8eNAix/1+NGIHocx7DAGGCYA+vHjIH4cxY8n8eNp 9DiK6Y5iHkZxE6O4iVHcxGgYP8ZNjOImRnETJ3ETJ3ETYKy29mhbtmVbtmVbtmVbtmVbtmVbtmVb tmVbtmVbtmVb/g+XfwPonD0GAKAAAA== ------------110115E3E248818-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 4 7:12:21 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7CD637B400 for ; Wed, 4 Sep 2002 07:12:13 -0700 (PDT) Received: from ksue.kharkov.ukrtel.net (ksue.kharkov.ukrtel.net [195.5.57.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id D87B643EAC for ; Wed, 4 Sep 2002 07:12:05 -0700 (PDT) (envelope-from hw@ksue.edu.ua) Received: from LONELYPC.TECIS (lonelypc.local [192.168.0.3]) by ksue.kharkov.ukrtel.net (8.11.6/8.11.6) with ESMTP id g84EDD024133 for ; Wed, 4 Sep 2002 17:13:13 +0300 (EEST) (envelope-from hw@ksue.edu.ua) Date: Wed, 4 Sep 2002 12:36:26 +0300 From: Hard Wisdom , Kharkov@FreeBSD.ORG, State@FreeBSD.ORG, University@FreeBSD.ORG, of@FreeBSD.ORG, Economics@FreeBSD.ORG X-Mailer: The Bat! (v1.53d) Reply-To: Hard Wisdom , Kharkov@FreeBSD.ORG, State@FreeBSD.ORG, University@FreeBSD.ORG, of@FreeBSD.ORG, Economics@FreeBSD.ORG Organization: KSUE X-Priority: 3 (Normal) Message-ID: <13213006484.20020904123626@ksue.edu.ua> To: to Somebody it may concern Subject: [PATCH] Small contribution to FreeBSD Firewall configuration MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------110115E3E248818" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ------------110115E3E248818 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello freebsd-hackers, After some attempts to configure firewall (during last 2 years) I realized necessity to automate the task. So, output of my work is here: These scripts may be easely extended to implement another security model. I think, these must be placed at /usr/share/examples/ipfw, then user may wish to install them at /etc/firewall manually and invoke as: firewall_enable="YES" firewall_type="/etc/firewall/mirinda.load" Currently configured template file is for my particular computer (configuration is somewhat complicated, but shows all configuration possibilities implemented). I use only /bin/sh utility to produce necessary loadable configuration (and make utility too, but it doesn't matter now) -- Best regards, hw mailto:hw@ksue.edu.ua ------------110115E3E248818 Content-Type: application/x-compressed; name="ipfw_reload.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw_reload.tgz" H4sIAEjRdT0AA+08aXfbyJHzVfwVbYkJLUWiCICHNFpl1yM7L/N2nPj5SD7YHg4ENkVEJMDBYUnj 8X9PVXU3boAAJcreDdszEoSuqq6urq6jD0xtj9+Y83nXchcL1/luE0Xr9Ya9HvuOYcn+Zmw40geM jQaGofWHxqjPmKYbmvEd622Em0wJ/cD0GPvOc92gCu5mxvn8MRh63LL35PjSdo79Wau1x46Ojthr Pp1zK7Bdh5nOhC14YLKpadlzO7C5jyA1iyT4cAXo/WT7AXOn7JM5D4EZevJs83IOf/hLbtlTm0/Y 5R3rLD0+tW87LYAczwHr6T773EJt83nAfmdXHl+yn9saPPqAsesf//z+5/OPB+fHx7utL5tk3TEX dTn36nF+3j3YGNfPlksOWtDxA892rjo+C1wWzHiC5Y7qRwf4WZqeGQAgswN2YwczgDMtfgiEwMS4 N2wSLue2ZQaAJ4awNeHTdC/nrmXOSUpn9PO8rZ0xf2ZPA6rmgMfaVPFh90Obnlj74MO33v+J63SC lVLQ6opBVBP2mZAJPZ9LiSRgLu/GUHUW/wU8LloEMHU99YLZDkiR3k7c1o6sQbpYQbRbO1iDEO9Z W1ae0xMR+Mj++EdmuQ50P+RMR2hH8IFFcLcrKEVIu7JBCZgaWwG6qXF9DnPMgalnep55d8jsLu+y axtGGiYmDgS7DAM2McH22QFf+MwyHXbJE2Pqd7tdGjaikBk2n6MJdb2z6Kn+8CkMgrOnIOyj3+QI sI9nqHxOa0dA94TU5j5Xb37ht0tPQf+Jab+IcbYT4v2sGvhy3v5MgF8Ka8eqFsdiY/NLjYOaRErC 0eyS1nDc8cMpPpBTstw5cukLYwpkAveKg2Q80FY5QSOCkT3FwVqYy/WGqnAiCu2VU5dFI5eRIiKV ipgqYV4cbEi+L5xwwcEmoarP58pv2o5vTzgpegumOtQU2WDTu8K3UkHlX6iiaQEI4PEZmZMx2QsJ G5kT0fGDeLY/fl+DG5f667PQRwMNSof217qzwAMnhVAuCC0tCS0lihy0nobWc9ArhKcp6SkTKkEV bApYj6CUjVYij83wVxI8zQ2ctEvPnYQWZ0vT9kji8N9m1a5KYrE3+3YlFTr2r2GBwLJRwmNLDPz/ mD0B3w8A5Pa/GRGSM1azeaOeWcBBxMBvz8QvcMdpMd/MbPA/ICyqZkfwh/Ljacs4Pk87BYL/Ipsf Y9PjyIaqxqSnF6QjTy/F3iD/m6r8H/zYZrL/lfl/fzDsU/7fHw700UiD/F8b9fVt/v8YJZf/vwmX yzlfcAfEcsc8NwwoQLty4QdEWLz2hN7E5H9petdsYfq/hpBoTSjRmmIw3qJf40k02yFqdthu29gV BioO0jTW1jdjmN5Q0HrH+G3APYeMAzwgX2wCk8wK5neSTR6xGfFlTyGfAu52dvZYlMClanlRLcSz mCSMHdExrKcmcgAmAXw2/vCH44MvAGVOJl4OaEFABlIBGV/LDIQEywQP8IAgfYCY2J+4F2xWlCTB SlHa64jS/gZEaT+SKKlR6ilDQwfx79RzF6zDO+Ti88rqUwgigGwCQipqIMC/yMkWCV7kqDjbtF12 ZFK6+lnb2+MHX1TCKrvOVQ7A52VIdg7JjpEwz+XWzGU/OuAMbcgOCaQjunfEIFHVPuyC37y1A6ap 1HcjYiVDJGwPMGviag8EI5cQs+GiHEo2ZaWe0gKDTFtbe1ElJqhLzj1/v4WvQKbRkoJ4j53fAPsX rjO1r0JcrHKdxEokMu5zK/Ts4I4t3AmfH7Ir7nDPtphvzcAtfI9rWdy5G9vOYdxHfihegrc4hHjV 96Ea/+iyZ/OFC9OOm9aMeSF0d2Ziwm4HHR/kEaJeLUEtD5kPw8pm7pLD8IFUfZgTDFq0rv1ItiQu yO8nPJBidD2MkiHDn9hWQNXc81wvigcdDnkfjJTvToMbE4Dn5h33uijSzty96jDo778gAmCdDvMh WnPAsrCJ5y4ptoQOXLk4fEvTuuZq6kRzQRJvWVKYfAwkrwD+nOjjkqEVdEiMMMV9IWFBik1xHfAS CHBQ9IJJmCCK+OeC2EZsbRBeioEHQ2ajPgAjSzMA2dNqZ1odkIO3M+ijD+nKNSivveT+IYM0JZSW A8bRdRLs+zwIxaILTcTnoCbQT8tdJAWLgUUCRypYjPXMoUkFQ0jTCbnNDU6GhgRP00DCKzGVJpcw fZzDV+NYOHxETUJIil875kuWKP6f25ceRHybaGNF/G8YQyOK/4ejIe7/9Ufb+P9RSi7+/0nogbCz YApoQVZpSRPrsxljxZdLnHppl+WEi0uOGzQMd7HBCvmt6Q1Ynl/Pe2dMPI19QD3XehvZJLIsvgwY WTpyQpG4JDuCm2CMewmpgFV4eqidu+YEff1mNrEEf6EzcQvZk+EJuud9ZBUcwSpWAYS1hWSjhV21 h4VAoSN6JEA2FYPZDvPvIFG1AoxPZuGV6bUupFUB5hNSZ7t7DBfZPXgsr23REBZUUyX6uhhXCYnt 0nuEIC9YACDeIwRFPAUQ4j1CiFwgDyHfO2YwEawuubewCwDle4QxxbjnQOR7AqENyQIQeo8QGM0V 9hrfEyfkVAsg6D31CQOqIgB8TyQ8jpvbeQjxXgzcvyDmK4Kg9wgSOh6FmVkQ9Z5akmFBDmh6I+W6 qT0uCJYd84oWVshmXXluSKYsOxv9FlWxTIL1G6aLYuGQ9gClmkvzptYD5ZT8k3ois/dLIn+S4O1k ekTtjS/vlNZLYwkwmzgHQeYDjM47YSJIFphi0H44NB5yByOoxTVZGuQpsZwbGSDKAz+0xwgnjE0M SYl+bIQIFGJXyBoI42u73G+qRPEfhfebaaM6/tP68E/Ff8Zo1MP4TzOG2/jvMUou/ksvDTRf9k3O 9Xe4GII5pL1YznFBT3gxtHodMVc7eL4C2gIjQCsg44mb3d2iVZYz8atws8ZaLCZn9LOwGhX7jH5m qiO7qkdLTnI1b6eN1GgNgFJ+sLzQCxPc2SfbZG2xptZGkpFllagEh7+XrhcoOoG1lHQOlNUupCOs sRSD0VQM6/STnHjUTewg8A+9bdhNIhP3ErK5CjKJJbn3r8HcgwGafLy3YxE+EyzNGSvslBq8uduT sDrCUoyShdX0UbeH/45PJKwRwdqykwkYSV716YIO0t67R1GfBtj2Beu8f/IRJifGichv4JnTKUS9 eExznlw56qijXZEnpEXtDhE7a+1YEYki8eBeIxA7IyJ1YN0wEMAdGUewYYLfNwFEeP7Sdac458t5 jXa25ep9p7VD0p67V3HzH9q4sD6GRlNMYPfG7XHMtuJEcPHfH9lzsEDuIpX3JGycYCKzYNVSo/kD TK5r9qNc+7nHqCZ5MjUpmtd/udBOtRNcSvRRPHhyqWA1sHBMP/FiMclR6kXqGRmcSFZnFXjaSO9q Q0LV9CZ4p4h3IhCHWbz8uFwqGUxAk4MjiHwdEPDRxA/No57RDW4D9lSDHO8OJ2pvX4joqe1Y83AC Pun1izcvXv/jxfMj7bCjYmEg+/yvF6+YGQbuUWqMD9nfXrw9evvizdtD9vLdT29/vHj25i17as3R VDzfPxSnyuivF/tJenJMQMtpPTkakkcdkeFpVx/0SyRbPSK9Lvx/rPebtKfrfclpvxGfer9XgZfX AAs04Lmyv7klYaLsuEFuvb1kNtjFskcK1YajxG5MVnMH3MwpvsFGHmjaRvyayFodRoWBS6k7JVXY hFosz/KftXlywT2yekDwZbS3cx9XlmSUg0Tfa8fGx5i24o+WGyBWpD2vbrfLPDDCnlMiwPGERChW RLICbCa8KfKk1+PJduzAhiy1iqsoK0/mrGInT4W3CZ5kF8C6YGJaxN9VUgsz21DiXKOr1HAGWFez WA9xqzbHamK6VOjiKk+bdPpJN/l3uTPyUG5S36CbzFjjoo4WGruMf6yPl/aPxXgFblL/j3GTa49I 2j82GpGEf6yNl/GP9fHS/rGuBlh6wgTk9h6ly7ifk8z6nkXefObi/KTzyW+Ux3u1Ym8hsbeMR8q4 v591QRKllXbC+sf/Ovpz2goW78qXuODIPnZalAa30/vq7JyJnfXoasUeexlaMzbj5iebe+CHRD06 1afA4qU9yW37FjS730Tv0y6/MERJSB/S58buPxKZzBoL3T8ARf7/FU7xZ8IB3iuTTXL6BBLCVyo3 V/mrEqJwYmhfmhn2wmR/dQzwjShDmvv6SkBr+ZnceT2qlbpVOWL5w3n5fD42OgU8qQAj+iM7XDRe 62CmOlVqBysI64NBN/F/eSiplrGA7psgnE7vuezTZGLnT50UTmsJlh7YKfgUuSuccCTxcS4hksAL 6ZIMxa8lglwj6pXbj7ZTFvRy4O69gUE5KV+Rz1PBOZKv4q9uVG6khjfJ2H16baRnb2mQn/LwdI8t 59uuHffGqRyJyLm0cwfS6kb2xUkSsnb8k/RYOGn4JJ1H0j5uUUCBq6Jfe4NjWypLtP+3ND2fb6aN Fee/2Eg35PcfhsZooNH+X2/7/YdHKdn9v4crrS475oF1rDQsepCfGsGz8WKvhM1N5yo0r/CIOvjQ ckR5RhEQ/6KW8vGMGlo4WVWOi/ebsEk6jUG5iDg7hnlrwBfLuRnwHDbeE9jJHJcub4K20BH+jToz GxF+cOHK4xHsz239jEVnIOBPo5nFjZhXrG5Ax1ad/9S1+PwnWAGc/0N9O/8fpazY/8czgetc/jra zPnPf+KRfhn2RYu1cluxKPu3zNDn7IauZeBnAmZ8wS4hwjrE1VGMUGaue50OtjAFpS98cAijaHXf tIIQGrhDAp7p+As7oCMM+HmILntH18nxejmdzZuYfIGmhS44LF3ft8WlBUBGVhAuYhQM17WPhyPC eWByN/TndyLCt6dTELYTMGtuwy+/K67cxCnX9HaJx2SiJUUNF75QKBIQmhj7eIJvuRSAgy78G3VH o2NDzwJOTTwudbvU2EmvCyRxfeukd6yfCEBxgs0EHsXSDbMpAqeQUbVD1zdu5OAkFn9UpJ68QiT7 hHUoEWodj+jNxfcaUtI5pO9w+Nz7xPEaEl0EQaQImm4cYEdTaN3CewDq6F/cy+EgccaDsuRIHqk9 /QfUYUpY4oEzGJ6Ic/j87tVFtq7P8Izrrb3IVgyg4u+eac15K1ul9TSofMWXvo1bFi5uDOABC7wZ fM3v8N1TmDr2ZH8jJ3J/cG9Rcv/75t0LUIdLNXLZThtiexKVUutqJ/oqAAOPfj97gS9fuRPTgzl7 MTODNJrR1TRN7EN2tVOte6J1T3tlIL3TrjYAcRm9rq5VAOn90+6wD782chbyby506+UPz9CERQqs VnBbE5cyeLwUJg7KnpXk9nRSSELHx3ASpzU0Y7Si/mRF/WlUH06q6RfXn6yoP/3GrsX8x5SFeQ0B 8XxDmZ8oGP/1+6Xxn96T93+ModbvYyyo9UbDwTb+e4zysEYNbBp7FgbuwqQbGZwCJR/ctTzhDSEl fjdrjzUqTy/2mX5y9Cy8OtJ7Pf0OP5N38Nd/HrT2Wi17Ob3ZOd859jGKxT/Y0a+tS9Pn+DKZprWs 6c6T852Z6wfiurD/0Ba95fHIPn+/0/5sTb90MSnrOvzmwdtKk1fNifajg27dg9bOjh9f3xKLPCwF +wFA8iJPk5d/ihxTdCdJ4/udXBYJRNGPZF+z9v88uCQgNLhzrJnnOvZviTN+GBlSEK60EIYH2f8e WGt/Rk35QreYhv0e5KbivkvR+uXOznt25KUkQBKi70ooQu3PqHJfjnNQv/+eJhBJVBJYfMpXxC8K CMRjkCGQqEhxUcSBHOSKLiBUQlDy9gTJauun/z+Vhe3ZzsSUM3kzbTRb/xng+k9vtPX/j1K26z/b 9Z/t+s92/ecBurZd/2kqr+36z3b95ysXFf9hwL+pNqrXf3RNB+cl4z9IMHT8/uNgpG3jv8comALD +Ky+NImAOgCuvDGJgIYCrLguucdq3mgkigOtx6qvI1JMZDtNoPHIK4Hrq8ApjlLE60FHxI0avGgR 8XrQSFwIcMUVSyI6VMNRciNBy5ybT/a2KW6yM2W4qWi0ZAjXwF3Rbja6bdRwBbKSFozHysumCNT0 9qfgSi/iKnezUPGzGid9j6UBXv6eZz3ENJM4XOswWRMvzyQhgvQf7t4pJkYPcI8GyJRdnxEdNdYY +SqcgvukNRGTF2bqoyXvyzTAStyWqY9VpmQN5VETMSuPemhZedTEyshD6fO6t2hbcvG7oEWErzTw ytw9wB1ZwcagouOCm8js5x3UKuSk6U65ishgN7s8i3jN77IKXkc9lvySV16jKvq5Areqm+tccxWN npQ0mlzCKIt8aiD374M8uA8yrpTURY9y4oo1jAehYqxBpXDd4150Uosj96UUr6CsNUxGxvRoa2tX U+TBfZAz2lWJXlu77kvFWINKuXatSyevXfeglNGuZG50z6vzgpnTNRKnqCcNkZPMN736Tg2OCjOX OCTKMFqBk467G+CVXnJfgVjIZBQYNWRyFV4pk1GO8GCX7h8pRxhpa4x8IU75ZfpViMlguD5aMhhu gJUIhutjrVCyhvJYhVgijxVoJfJYhVUsjyhHWOsTAqK9qjS7IFFIra1FAfY6HwgQzUNKhJ9mLd6z S4W88bLiw301QPBQkSTF4XqZFyjHLuA+5wfWud1PC4Nr37UXTA9LVoSrEpRSpNLMpBirllRzWHWk 2fQ+u2hqlGcw68LLJoHq4z1IRD2uQaPo2noiXW9+o1y0jBEZ7kCWbS3WADqpA3SaBirbaawBdFIH 6JQy4+Y34QVtCO7kRfYaWUusCZVoWeNdEy2bqdREy+coRYhNspM18Y1G+JUZSUMKhblIcxr5LERN ubU+ZUCNn5RtyiW1LGuCayD110EarIOE+lWKlhBorEbp3lV0rwDbWAM7pUEJdDG4NfDT+rMmhYT2 1KewSiuSLra2VjREGqyDpLSiEK22VtTFLtaKauzVWrECv4ZWrKawSisait3IRxRN1KIR1mAtrIRi FOA10Yx66KWqUYVeSzcqCdRTjlUkamhHlII1/LyMaFWlmfXWraS7q/hSjKCq97Yfi/m2ijr/JW6L bKaNFff/WN/Inv/anv9/rCJv9sAQteSjHj8a8eNAix/1+NGIHocx7DAGGCYA+vHjIH4cxY8n8eNp 9DiK6Y5iHkZxE6O4iVHcxGgYP8ZNjOImRnETJ3ETJ3ETYKy29mhbtmVbtmVbtmVbtmVbtmVbtmVb tmVbtmVbtmVb/g+XfwPonD0GAKAAAA== ------------110115E3E248818-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 4 9:20: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7533137B400; Wed, 4 Sep 2002 09:19:59 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3311B43E6E; Wed, 4 Sep 2002 09:19:58 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g84GJcOo059096; Wed, 4 Sep 2002 12:19:38 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 4 Sep 2002 12:19:38 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: hackers@FreeBSD.org, developers@FreeBSD.org Subject: Request for submissions: FreeBSD Bi-Monthly Development Status Report Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a solicitation for submissions for the July 2002 - August 2002 FreeBSD Bi-Monthly Development Status Report. All submissions are due by September 13, 2002. Submissions should be made by filling out the template found at: http://www.FreeBSD.org/news/status/report-sample.xml Submissions must then be e-mailed to the following address: robert+freebsd.monthly@cyrus.watson.org For automatic processing. Reports must be submitted in the XML format described, or they will be silently dropped. Submissions made to other e-mail addresses will be ignored. If more than one report is submitted for a project, the latest instance will be used. Status reports should be submitted once per project, although project developers may choose to submit additional reports on specific sub-projects of substantial size. Status reports are typically one or two short paragraphs, but the text may be up to 20 lines in length. Submissions are welcome on a variety of topics relating to FreeBSD, including development, documentation, advocacy, and development processes. Submitting developer status reports help maintain an important link between FreeBSD developers, as well as a link to the user and sponsor communities. By submitting a report, you help share information about the rapid progress made by the project, making it easier for advocates to point at the excellent work that's being done! Prior status reports may be viewed at: http://www.FreeBSD.org/news/status/ Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Sep 4 22:32:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6306637B400; Wed, 4 Sep 2002 22:32:44 -0700 (PDT) Received: from mail.netizen.com.ar (mail.netizen.com.ar [200.49.100.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id D107843E3B; Wed, 4 Sep 2002 22:32:38 -0700 (PDT) (envelope-from foxe@american.co.jp) Received: from pokemonarena.net (adsl103071.netizen.com.ar [200.49.103.71] (may be forged)) by mail.netizen.com.ar (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id CAA30610; Thu, 5 Sep 2002 02:32:04 -0300 From: foxe@american.co.jp Message-ID: <000005d67194$00002cf1$00007583@american.co.jp> To: Subject: Cell Phone Car Chargers/Ear Buds/Holders Only $1.95!! 30083 Date: Wed, 04 Sep 2002 08:35:53 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Cellular Phone Accessories All At Below Wholesale Prices! http://www.cell2002.com.zw@x.y4h37z.te.ua/go.php?id=1109I Hands Free Ear Buds 1.99! Phone Holsters 1.98! Booster Antennas Only $0.99 Phone Cases 1.98! Car Chargers 1.98! Face Plates As Low As 0.99! Lithium Ion Batteries As Low As 6.94! http://www.cell2002.com.zw@x.y4h37z.te.ua/go.php?id=1109I Click Below For Accessories On All NOKIA, MOTOROLA LG, NEXTEL, SAMSUNG, QUALCOMM, ERICSSON, AUDIOVOX PHONES At Below WHOLESALE PRICES! http://www.cell2002.com.zw@x.y4h37z.te.ua/go.php?id=1109I ***If You Need Assistance Please Call Us (732) 751-1457*** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To be removed from future mailings please send your remove request to: removemenow68994@btamail.net.cn Thank You and have a super day :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 1:54:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7973837B401 for ; Thu, 5 Sep 2002 01:54:10 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 197BE43E65 for ; Thu, 5 Sep 2002 01:54:06 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 1468 invoked by uid 1000); 5 Sep 2002 08:54:08 -0000 Date: Thu, 5 Sep 2002 01:54:08 -0700 (PDT) From: Nate Lawson To: hackers@freebsd.org, scsi@freebsd.org Subject: New scsi_target code Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have rewritten the scsi_target driver and usermode client with a much simpler model suggested by Justin Gibbs. The kernel driver receives commands in the form of CCBs via write(2) and returns completed CCBs to usermode via read(2). The included sample client is much simpler as well, implementing only RBC (simple hard drive command set). What is this useful for? It allows anyone with an HBA to emulate various SCSI target devices for reverse engineering initiator implementations, debugging, host-host communication, and many other uses. Because it operates at the CAM layer, it should work with multiple transports (parallel SCSI, FC, ...) Currently, the code works to the point of passing camcontrol rescan and a few reads and writes with two Adaptec 2940U2Ws (ahc driver). However, there is an unknown bug where after a few commands (even just TUR), the target hangs after sending a CTIO and the initiator aborts the command. As such, the code is ALPHA QUALITY and may hang your system. For more information, see the included README and manpages. Comments are needed and appreciated. http://www.root.org/~nate/freebsd/ -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 2:32:51 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8005437B401 for ; Thu, 5 Sep 2002 02:32:47 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id 01D0F43E72 for ; Thu, 5 Sep 2002 02:32:46 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 14119 invoked by uid 1031); 5 Sep 2002 09:24:27 -0000 Date: Thu, 5 Sep 2002 10:24:26 +0100 From: Bruce M Simpson To: Nate Lawson Cc: hackers@freebsd.org, scsi@freebsd.org Subject: Re: New scsi_target code Message-ID: <20020905092426.GA9129@spc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Nate, On Thu, Sep 05, 2002 at 01:54:08AM -0700, Nate Lawson wrote: > I have rewritten the scsi_target driver and usermode client with a much > simpler model suggested by Justin Gibbs. The kernel driver receives This sounds like excellent work and I can't wait to check it out further. Whilst looking into the problem of USB->ATA bridge support I was recently faced with the problem of writing various ATA->SCSI command translations, which involved emulating a SCSI device, so I imagine your code should be very useful. Thank you! BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 9: 3:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6B8537B401 for ; Thu, 5 Sep 2002 09:03:10 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAEF843E3B for ; Thu, 5 Sep 2002 09:03:09 -0700 (PDT) (envelope-from mb@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.3/8.12.3) with ESMTP id g85G38O9098149; Thu, 5 Sep 2002 18:03:08 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by nbs.imp.ch (8.12.3/8.12.3) with ESMTP id g85G3875383310; Thu, 5 Sep 2002 18:03:08 +0200 (MES) Date: Thu, 5 Sep 2002 18:08:23 +0200 (CEST) From: Martin Blapp To: Cc: Subject: FreeBSD Problems with dc(4) ADMtek AN985 chip Message-ID: <20020905161357.C31964-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi everybody, (I also wrote to the linux tulip list, maybe someone has encountered the bug in linux too as I do ?) My notebook has a Accton EN2242 network chip, which is integrated into a VIA PN133 chipset. I encounter serious connection problems as desribed in the manpage. I have to replug the cable over and over again till it works. And then the connection stays about some seconds and then it get wedged again. Unusable ... From a cold boot into Linux, is see the same symptoms as FreeBSD. Linux kernel 2.4.9-13 ... The windows driver seems to work :-( . From the FreeBSD dc manpage. The ADMtek AL981 chip (and possibly the AN985 as well) has been observed to sometimes wedge on transmit: this appears to happen when the driver queues a sequence of frames which cause it to wrap from the end of the transmit descriptor ring back to the beginning. The dc driver attempts to avoid this condition by not queuing any frames past the end of the transmit ring during a single invocation of the dc_start() routine. This workaround has a negligible impact on transmit performance. But this workaround seems not to work for me. For some reason, replugging the cable works for me, ifconfig (down/up) does not. Whe link always stays up, it is just the reciever queue with is wedged. Have other people the same problem with the dc driver ? If you own such a card here: Linksys EtherFast LNE100TX Accton EN2242 Please tell me your experiences. Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 10: 5:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CED2737B400 for ; Thu, 5 Sep 2002 10:05:35 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2307043E81 for ; Thu, 5 Sep 2002 10:05:35 -0700 (PDT) (envelope-from phoenix@minion.de) Received: from [212.227.126.155] (helo=mrelayng1.kundenserver.de) by moutng5.kundenserver.de with esmtp (Exim 3.35 #2) id 17n04T-0007pS-00 for freebsd-hackers@freebsd.org; Thu, 05 Sep 2002 19:05:33 +0200 Received: from [80.144.28.93] (helo=chronos) by mrelayng1.kundenserver.de with asmtp (Exim 3.35 #1) id 17n04S-0000s7-00 for freebsd-hackers@freebsd.org; Thu, 05 Sep 2002 19:05:33 +0200 Received: from phoenix by chronos with local (Exim 3.35 #1 (Debian)) id 17n03I-0000Hk-00 for ; Thu, 05 Sep 2002 19:04:20 +0200 Date: Thu, 5 Sep 2002 19:04:20 +0200 From: Christian Zander To: freebsd-hackers@freebsd.org Subject: double page fault(s) Message-ID: <20020905190420.H649@chronos> Reply-To: Christian Zander Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.22.1i X-Operating-System: GNU/Linux [2.4.19][i686] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi all, I've been experiencing double page faults on several FreeBSD 4.x systems with a custom device driver, which I believe is somehow responsible. Searching the freebsd-hackers mailing list archives I found several mentions of problems similar to mine; it seemed that the consensus is that this problem is almost always caused by kernel stack mistreatment. I spent quite a bit of time trying to approach the problem with DDB and KGDB, but while I'm able to break into the debugger when the second fault occurs, I have not yet been able to investigate the offending stack. One approach I've looked at was suggested in response to the "Debugging double page fault" thread; it was (if I understand it correctly) suggested that if one can find a way to break on the second handler, then by saving a copy of or a reference to the first trap frame in the first fault handler, one would be able to investigate that frame (from said second). Unfortunately, my knowledge of the FreeBSD kernel is still poor, I'm unsure about the appropriate places to catch the first trap and where to save the fault frame. I'm hoping that you can point me at additional sources of information or have other hints. Thanks, -- christian zander zander@minion.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 10:22:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DD3737B400 for ; Thu, 5 Sep 2002 10:22:20 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC3CF43E72 for ; Thu, 5 Sep 2002 10:22:19 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020905172009.TKNE1399.rwcrmhc51.attbi.com@InterJet.elischer.org>; Thu, 5 Sep 2002 17:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA37091; Thu, 5 Sep 2002 10:16:19 -0700 (PDT) Date: Thu, 5 Sep 2002 10:16:18 -0700 (PDT) From: Julian Elischer To: Christian Zander Cc: freebsd-hackers@freebsd.org Subject: Re: double page fault(s) In-Reply-To: <20020905190420.H649@chronos> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG if you know which process stack was operational at the first page fault, then you can dump THAT stack with 'tr PID' the error messages MIGHT give thatinfo.. failing that you MAY have to try all the active pids (ps in ddb should give you a hint as to which to try.. it will not be sleeping) until you find one which has a stack that is in the right neighborhood. It MAY not work however.. it all depends on a number of factors, such as teh last time the process run and how much damage has occured. Also the previos stack pointer is savevd among the stuff saved on the double fault.. you MAY be able to find it.... (check an x86 manual) Then you can dump it using x/xxxxxxxxxxxxxxxxx and maybe you can back track it by hand.. just some ideas... On Thu, 5 Sep 2002, Christian Zander wrote: > Hi all, > > I've been experiencing double page faults on several FreeBSD 4.x > systems with a custom device driver, which I believe is somehow > responsible. Searching the freebsd-hackers mailing list archives > I found several mentions of problems similar to mine; it seemed > that the consensus is that this problem is almost always caused > by kernel stack mistreatment. > > I spent quite a bit of time trying to approach the problem with > DDB and KGDB, but while I'm able to break into the debugger when > the second fault occurs, I have not yet been able to investigate > the offending stack. One approach I've looked at was suggested > in response to the "Debugging double page fault" thread; it was > (if I understand it correctly) suggested that if one can find a > way to break on the second handler, then by saving a copy of or > a reference to the first trap frame in the first fault handler, > one would be able to investigate that frame (from said second). > > Unfortunately, my knowledge of the FreeBSD kernel is still poor, > I'm unsure about the appropriate places to catch the first trap > and where to save the fault frame. I'm hoping that you can point > me at additional sources of information or have other hints. > > Thanks, > > -- > christian zander > zander@minion.de > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 11: 7:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1FEE37B400 for ; Thu, 5 Sep 2002 11:07:38 -0700 (PDT) Received: from spork.pantherdragon.org (spork.pantherdragon.org [206.29.168.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 154A043E4A for ; Thu, 5 Sep 2002 11:07:38 -0700 (PDT) (envelope-from dmp@pantherdragon.org) Received: from sparx.pantherdragon.org (evrtwa1-ar10-4-61-252-210.evrtwa1.dsl-verizon.net [4.61.252.210]) by spork.pantherdragon.org (Postfix) with ESMTP id 17731FDDC; Thu, 5 Sep 2002 11:07:37 -0700 (PDT) Received: from pantherdragon.org (speck.techno.pagans [172.21.42.2]) by sparx.pantherdragon.org (Postfix) with ESMTP id 76D0CA910; Thu, 5 Sep 2002 11:07:34 -0700 (PDT) Message-ID: <3D779D66.E29FCEEB@pantherdragon.org> Date: Thu, 05 Sep 2002 11:07:34 -0700 From: Darren Pilgrim X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Blapp Cc: hackers@freebsd.org, tulip-bug@scyld.com Subject: Re: FreeBSD Problems with dc(4) ADMtek AN985 chip References: <20020905161357.C31964-100000@levais.imp.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Martin Blapp wrote: > Have other people the same problem with the dc driver ? If you own > such a card here: > > Linksys EtherFast LNE100TX > Accton EN2242 > > Please tell me your experiences. I have an LNE100TX in a machine that has run 4.5-R, 4.6-R, RELENG_4_6, RELENG_4, then back to RELENG_4_6 again. Probe details on 4.6.2-R with dc compiled in: dc0: port 0xd800-0xd8ff mem 0xdf104000-0xdf1043ff irq 9 at device 10.0 on pci1 dc0: Ethernet address: 00:04:5a:59:7c:a8 miibus1: on dc0 ukphy0: on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto The NIC is the external interface on my gateway. It was originally connected to an old HP 8-port 10bT hub and is now connected directly to a Westel DSL bridge. It has worked seemingly without problems handling the 768/128 DSL traffic. I say seemingly because I've never bothered to really push the NIC and I've never seen any link-level problems. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 11: 9:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F9ED37B400 for ; Thu, 5 Sep 2002 11:09:31 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2273843E4A for ; Thu, 5 Sep 2002 11:09:30 -0700 (PDT) (envelope-from mb@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.3/8.12.3) with ESMTP id g85I9TO9013579; Thu, 5 Sep 2002 20:09:29 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by nbs.imp.ch (8.12.3/8.12.3) with ESMTP id g85I9T75387063; Thu, 5 Sep 2002 20:09:29 +0200 (MES) Date: Thu, 5 Sep 2002 20:14:44 +0200 (CEST) From: Martin Blapp To: Darren Pilgrim Cc: , Subject: Re: FreeBSD Problems with dc(4) ADMtek AN985 chip In-Reply-To: <3D779D66.E29FCEEB@pantherdragon.org> Message-ID: <20020905201401.K31964-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, > The NIC is the external interface on my gateway. It was originally > connected to an old HP 8-port 10bT hub and is now connected directly to > a Westel DSL bridge. It has worked seemingly without problems handling > the 768/128 DSL traffic. I say seemingly because I've never bothered > to really push the NIC and I've never seen any link-level problems. > 10 or 100 mbit with your Westel DSL bridge ? Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 11:18:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3392D37B400 for ; Thu, 5 Sep 2002 11:18:15 -0700 (PDT) Received: from spork.pantherdragon.org (spork.pantherdragon.org [206.29.168.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCC3043E6A for ; Thu, 5 Sep 2002 11:18:14 -0700 (PDT) (envelope-from dmp@pantherdragon.org) Received: from sparx.pantherdragon.org (evrtwa1-ar10-4-61-252-210.evrtwa1.dsl-verizon.net [4.61.252.210]) by spork.pantherdragon.org (Postfix) with ESMTP id 53351FDDC; Thu, 5 Sep 2002 11:18:13 -0700 (PDT) Received: from pantherdragon.org (speck.techno.pagans [172.21.42.2]) by sparx.pantherdragon.org (Postfix) with ESMTP id E48DAA910; Thu, 5 Sep 2002 11:18:11 -0700 (PDT) Message-ID: <3D779FE3.AC55EA69@pantherdragon.org> Date: Thu, 05 Sep 2002 11:18:11 -0700 From: Darren Pilgrim X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Blapp Cc: hackers@freebsd.org, tulip-bug@scyld.com Subject: Re: FreeBSD Problems with dc(4) ADMtek AN985 chip References: <20020905201401.K31964-100000@levais.imp.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Martin Blapp wrote: > > Hi, > > > The NIC is the external interface on my gateway. It was originally > > connected to an old HP 8-port 10bT hub and is now connected directly to > > a Westel DSL bridge. It has worked seemingly without problems handling > > the 768/128 DSL traffic. I say seemingly because I've never bothered > > to really push the NIC and I've never seen any link-level problems. > > > > 10 or 100 mbit with your Westel DSL bridge ? 10mbit half-duplex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 11:19:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FA8337B400 for ; Thu, 5 Sep 2002 11:19:43 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41C0F43E6E for ; Thu, 5 Sep 2002 11:19:42 -0700 (PDT) (envelope-from mb@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.3/8.12.3) with ESMTP id g85IJfO9014606; Thu, 5 Sep 2002 20:19:41 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by nbs.imp.ch (8.12.3/8.12.3) with ESMTP id g85IJe75387177; Thu, 5 Sep 2002 20:19:40 +0200 (MES) Date: Thu, 5 Sep 2002 20:24:55 +0200 (CEST) From: Martin Blapp To: Darren Pilgrim Cc: , Subject: Re: FreeBSD Problems with dc(4) ADMtek AN985 chip In-Reply-To: <3D779FE3.AC55EA69@pantherdragon.org> Message-ID: <20020905202349.V31964-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I have a 100mbit full-duplex connection, maybe this is the difference ? > 10mbit half-duplex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 11:22:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54FED37B400 for ; Thu, 5 Sep 2002 11:22:33 -0700 (PDT) Received: from spork.pantherdragon.org (spork.pantherdragon.org [206.29.168.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA8A843E6A for ; Thu, 5 Sep 2002 11:22:32 -0700 (PDT) (envelope-from dmp@pantherdragon.org) Received: from sparx.pantherdragon.org (evrtwa1-ar10-4-61-252-210.evrtwa1.dsl-verizon.net [4.61.252.210]) by spork.pantherdragon.org (Postfix) with ESMTP id 730E9FDDC; Thu, 5 Sep 2002 11:22:32 -0700 (PDT) Received: from pantherdragon.org (speck.techno.pagans [172.21.42.2]) by sparx.pantherdragon.org (Postfix) with ESMTP id C6CC5A910; Thu, 5 Sep 2002 11:22:31 -0700 (PDT) Message-ID: <3D77A0E7.F2A64B4D@pantherdragon.org> Date: Thu, 05 Sep 2002 11:22:31 -0700 From: Darren Pilgrim X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Blapp Cc: hackers@freebsd.org, tulip-bug@scyld.com Subject: Re: FreeBSD Problems with dc(4) ADMtek AN985 chip References: <20020905202349.V31964-100000@levais.imp.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Martin Blapp wrote: > > Hi, > > I have a 100mbit full-duplex connection, maybe this is the difference ? > > > 10mbit half-duplex Since the issue seems to be the sort where high amounts of traffic would be a triggering factor, it's quite possible. Give me 20 minutes or so and I'll go swap the interfaces around so the dc is on the inside connected to 100mbit/full and flood the link. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 12:17:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D641337B400 for ; Thu, 5 Sep 2002 12:17:28 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id AE8DC43E72 for ; Thu, 5 Sep 2002 12:17:27 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 23759 invoked by uid 1031); 5 Sep 2002 19:15:46 -0000 Date: Thu, 5 Sep 2002 20:15:46 +0100 From: Bruce M Simpson To: freebsd-hackers@freebsd.org, imp@freebsd.org Subject: PCMCIA questions: mapping attribute and common memory? Message-ID: <20020905191546.GF15218@spc.org> Mail-Followup-To: Bruce M Simpson , freebsd-hackers@freebsd.org, imp@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hey there, I have a few questions regarding a PCMCIA driver I'm writing. How do I map in attribute and common memory blocks from a PCMCIA card? Is this done on my behalf by the pcic(4) driver? Does it scan the CIS tuples for me and perform the appropriate allocations? If so, how do I get at the resource? If not, how would I go about doing this myself in the driver? And what would I want to put in my driver's xxx_probe() routine? I've been looking over the ray(4) and xe(4) drivers, which have given me some hints, but I'd appreciate clarification. Thanks! BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 12:22:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B41AA37B400; Thu, 5 Sep 2002 12:22:30 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC8FD43E3B; Thu, 5 Sep 2002 12:22:29 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g85JMBAg002077; Thu, 5 Sep 2002 21:22:20 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce M Simpson Cc: freebsd-hackers@FreeBSD.ORG, imp@FreeBSD.ORG Subject: Re: PCMCIA questions: mapping attribute and common memory? In-Reply-To: Your message of "Thu, 05 Sep 2002 20:15:46 BST." <20020905191546.GF15218@spc.org> Date: Thu, 05 Sep 2002 21:22:11 +0200 Message-ID: <2076.1031253731@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020905191546.GF15218@spc.org>, Bruce M Simpson writes: >Hey there, > >I have a few questions regarding a PCMCIA driver I'm writing. > >How do I map in attribute and common memory blocks from a PCMCIA card? >Is this done on my behalf by the pcic(4) driver? >Does it scan the CIS tuples for me and perform the appropriate allocations? >If so, how do I get at the resource? >If not, how would I go about doing this myself in the driver? >And what would I want to put in my driver's xxx_probe() routine? Suggest you look at the sys/dev/sio/sio_pccard.c file... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 12:45:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B132637B406 for ; Thu, 5 Sep 2002 12:45:34 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id C4A8943E6A for ; Thu, 5 Sep 2002 12:45:31 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 17333 invoked by uid 1031); 5 Sep 2002 19:43:42 -0000 Date: Thu, 5 Sep 2002 20:43:41 +0100 From: Bruce M Simpson To: Poul-Henning Kamp Cc: freebsd-hackers@FreeBSD.ORG, imp@FreeBSD.ORG Subject: Re: PCMCIA questions: mapping attribute and common memory? Message-ID: <20020905194341.GH9129@spc.org> Mail-Followup-To: Bruce M Simpson , Poul-Henning Kamp , freebsd-hackers@FreeBSD.ORG, imp@FreeBSD.ORG References: <20020905191546.GF15218@spc.org> <2076.1031253731@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2076.1031253731@critter.freebsd.dk> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Sep 05, 2002 at 09:22:11PM +0200, Poul-Henning Kamp wrote: > Suggest you look at the sys/dev/sio/sio_pccard.c file... I forgot to mention I'm working on -STABLE. =o) BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 13: 6:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47A6D37B400; Thu, 5 Sep 2002 13:06:23 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CD7043E77; Thu, 5 Sep 2002 13:06:22 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g85JlcAg002493; Thu, 5 Sep 2002 21:47:38 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce M Simpson Cc: freebsd-hackers@FreeBSD.ORG, imp@FreeBSD.ORG Subject: Re: PCMCIA questions: mapping attribute and common memory? In-Reply-To: Your message of "Thu, 05 Sep 2002 20:43:41 BST." <20020905194341.GH9129@spc.org> Date: Thu, 05 Sep 2002 21:47:38 +0200 Message-ID: <2492.1031255258@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message <20020905194341.GH9129@spc.org>, Bruce M Simpson writes: >On Thu, Sep 05, 2002 at 09:22:11PM +0200, Poul-Henning Kamp wrote: >> Suggest you look at the sys/dev/sio/sio_pccard.c file... > >I forgot to mention I'm working on -STABLE. =o) "Don't", that's a dead end and very very different from how the NEWCARD world will look in the future. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 13:11:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1A1837B400 for ; Thu, 5 Sep 2002 13:11:56 -0700 (PDT) Received: from spork.pantherdragon.org (spork.pantherdragon.org [206.29.168.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CB7C43E42 for ; Thu, 5 Sep 2002 13:11:56 -0700 (PDT) (envelope-from dmp@pantherdragon.org) Received: from sparx.pantherdragon.org (evrtwa1-ar10-4-61-252-069.evrtwa1.dsl-verizon.net [4.61.252.69]) by spork.pantherdragon.org (Postfix) with ESMTP id 72DE3FDDC; Thu, 5 Sep 2002 12:48:15 -0700 (PDT) Received: from pantherdragon.org (speck.techno.pagans [172.21.42.2]) by sparx.pantherdragon.org (Postfix) with ESMTP id 633A2AB39; Thu, 5 Sep 2002 12:48:12 -0700 (PDT) Message-ID: <3D77B4FC.8CC8A248@pantherdragon.org> Date: Thu, 05 Sep 2002 12:48:12 -0700 From: Darren Pilgrim X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Martin Blapp , hackers@freebsd.org, tulip-bug@scyld.com Subject: Re: FreeBSD Problems with dc(4) ADMtek AN985 chip References: <20020905202349.V31964-100000@levais.imp.ch> <3D77A0E7.F2A64B4D@pantherdragon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Darren Pilgrim wrote: > Martin Blapp wrote: > > I have a 100mbit full-duplex connection, maybe this is the difference ? > > > > > 10mbit half-duplex > > Since the issue seems to be the sort where high amounts of traffic > would be a triggering factor, it's quite possible. Give me 20 minutes > or so and I'll go swap the interfaces around so the dc is on the > inside connected to 100mbit/full and flood the link. I swapped the NICs around and hammered the LNE100TX for at least 30 minutes straight. I didn't get any problems. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 13:23:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F4D837B400 for ; Thu, 5 Sep 2002 13:23:57 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id 308E843E6A for ; Thu, 5 Sep 2002 13:23:56 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 2091 invoked by uid 1031); 5 Sep 2002 20:22:16 -0000 Date: Thu, 5 Sep 2002 21:22:16 +0100 From: Bruce M Simpson To: Poul-Henning Kamp Cc: freebsd-hackers@FreeBSD.ORG, imp@FreeBSD.ORG Subject: Re: PCMCIA questions: mapping attribute and common memory? Message-ID: <20020905202216.GI9129@spc.org> Mail-Followup-To: Bruce M Simpson , Poul-Henning Kamp , freebsd-hackers@FreeBSD.ORG, imp@FreeBSD.ORG References: <20020905194341.GH9129@spc.org> <2492.1031255258@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2492.1031255258@critter.freebsd.dk> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Sep 05, 2002 at 09:47:38PM +0200, Poul-Henning Kamp wrote: > >I forgot to mention I'm working on -STABLE. =o) > "Don't", that's a dead end and very very different from how the > NEWCARD world will look in the future. After playing with 'pccardc enabler' and looking at if_xe.c, I now understand why OLDCARD Sucks(tm). I'm eager to get this particular device working on my present platform though, so I'm going to fight on, with the intention of porting it to NEWCARD as soon as possible. BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 13:59:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A851437B401 for ; Thu, 5 Sep 2002 13:59:45 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CE0943E3B for ; Thu, 5 Sep 2002 13:59:44 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g85KxgGq010740; Thu, 5 Sep 2002 14:59:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Sep 2002 14:59:36 -0600 (MDT) Message-Id: <20020905.145936.39157187.imp@bsdimp.com> To: bms@spc.org Cc: freebsd-hackers@freebsd.org Subject: Re: PCMCIA questions: mapping attribute and common memory? From: "M. Warner Losh" In-Reply-To: <20020905191546.GF15218@spc.org> References: <20020905191546.GF15218@spc.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020905191546.GF15218@spc.org> Bruce M Simpson writes: : How do I map in attribute and common memory blocks from a PCMCIA card? You generally don't map attribute memory. With one exception (the raylan cards), there's no hardware in the attribute memory section and it is just used to store the cis. : Is this done on my behalf by the pcic(4) driver? Yes. : Does it scan the CIS tuples for me and perform the appropriate allocations? Yes. : If so, how do I get at the resource? : If not, how would I go about doing this myself in the driver? bus_alloc_resource() : And what would I want to put in my driver's xxx_probe() routine? Ideally, you'd just match the OEM ID and vendor info of the card. Less ideally, you'd match the strings in the CIS. : I've been looking over the ray(4) and xe(4) drivers, which have given me : some hints, but I'd appreciate clarification. Those are the two worst ones to look at. Don't do what they do, as the ray(4) hardware is weird and the xe(4) driver was written before we could read the cis from the kernel. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 14: 2:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C71937B400 for ; Thu, 5 Sep 2002 14:02:48 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0B1B43E42 for ; Thu, 5 Sep 2002 14:02:47 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g85L2PGq010758; Thu, 5 Sep 2002 15:02:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Sep 2002 15:01:55 -0600 (MDT) Message-Id: <20020905.150155.35013088.imp@bsdimp.com> To: phk@critter.freebsd.dk Cc: bms@spc.org, freebsd-hackers@FreeBSD.ORG Subject: Re: PCMCIA questions: mapping attribute and common memory? From: "M. Warner Losh" In-Reply-To: <2492.1031255258@critter.freebsd.dk> References: <20020905194341.GH9129@spc.org> <2492.1031255258@critter.freebsd.dk> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <2492.1031255258@critter.freebsd.dk> Poul-Henning Kamp writes: : In message <20020905194341.GH9129@spc.org>, Bruce M Simpson writes: : >On Thu, Sep 05, 2002 at 09:22:11PM +0200, Poul-Henning Kamp wrote: : >> Suggest you look at the sys/dev/sio/sio_pccard.c file... : > : >I forgot to mention I'm working on -STABLE. =o) : : "Don't", that's a dead end and very very different from how the : NEWCARD world will look in the future. Actually, much of the pccard driver interface is identical between the two systems. Look at the ep driver for a relatively sane way of dealing. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 14: 6: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C976F37B400 for ; Thu, 5 Sep 2002 14:06:02 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0676443E4A for ; Thu, 5 Sep 2002 14:06:02 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g85L5sGq010791; Thu, 5 Sep 2002 15:05:55 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 05 Sep 2002 15:05:47 -0600 (MDT) Message-Id: <20020905.150547.43851343.imp@bsdimp.com> To: bms@spc.org Cc: phk@critter.freebsd.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: PCMCIA questions: mapping attribute and common memory? From: "M. Warner Losh" In-Reply-To: <20020905202216.GI9129@spc.org> References: <20020905194341.GH9129@spc.org> <2492.1031255258@critter.freebsd.dk> <20020905202216.GI9129@spc.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020905202216.GI9129@spc.org> Bruce M Simpson writes: : On Thu, Sep 05, 2002 at 09:47:38PM +0200, Poul-Henning Kamp wrote: : > >I forgot to mention I'm working on -STABLE. =o) : > "Don't", that's a dead end and very very different from how the : > NEWCARD world will look in the future. : : After playing with 'pccardc enabler' and looking at if_xe.c, I now understand : why OLDCARD Sucks(tm). pccardc enabler sucks. if_xe.c in stable does all kinds of weird things. : I'm eager to get this particular device working on my present platform : though, so I'm going to fight on, with the intention of porting it to : NEWCARD as soon as possible. That's mostly doable. Most of the goo to have a driver support oldcard and newcard is present in -stable. I have some more good to MFC tonight or this weekend (just got RE approval). if_wi_pccard.c might be a better thing to look at for something that supports both oldcard and newcard in a sane way. Maybe if you provided more details on the hardware, I could provide more detailed answers, privately if necessary. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 18:48:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8AA337B400 for ; Thu, 5 Sep 2002 18:48:20 -0700 (PDT) Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9843C43E6E for ; Thu, 5 Sep 2002 18:48:18 -0700 (PDT) (envelope-from danfe@regency.nsu.ru) Received: from drweb by mail.nsu.ru with drweb-scanned (Exim 3.20 #1) id 17n8EJ-0007mp-00 for hackers@freebsd.org; Fri, 06 Sep 2002 08:48:15 +0700 Received: from regency.nsu.ru ([193.124.210.26]) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 17n8EI-0007mC-00 for hackers@freebsd.org; Fri, 06 Sep 2002 08:48:14 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.4/8.12.4) with ESMTP id g861nx5G011693 for ; Fri, 6 Sep 2002 08:49:59 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.4/8.12.4/Submit) id g861nxxn011597 for hackers@freebsd.org; Fri, 6 Sep 2002 08:49:59 +0700 (NOVST) Date: Fri, 6 Sep 2002 08:49:59 +0700 From: Alexey Dokuchaev To: hackers@freebsd.org Subject: Usenix 2002 FreeBSD Developer Summit III -- why no oggs? Message-ID: <20020906084959.A6251@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Envelope-To: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! I've read the notes as of 2 September, 2002 from the USENIX ATC 2002 FreeBSD Developer Summit, which were made available recently. As a very good addition to them, I suggest putting online some .oggs (or .mp3s) next time, with recorded speeches, just like guys from recent linux kernel summit did (ksmp3rep.sourceforge.net)? Sounds like a good idea to me. Opinions? ./danfe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Sep 5 21: 5:59 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 061C437B400 for ; Thu, 5 Sep 2002 21:05:58 -0700 (PDT) Received: from ambrisko.com (adsl-64-174-51-42.dsl.snfc21.pacbell.net [64.174.51.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81C0D43E4A for ; Thu, 5 Sep 2002 21:05:57 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.11.6/8.11.6) id g8644nx64631; Thu, 5 Sep 2002 21:04:49 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200209060404.g8644nx64631@ambrisko.com> Subject: Re: NS DP83820 gigabit MAC In-Reply-To: <20020903194059.GN2409@spc.org> To: Bruce M Simpson Date: Thu, 5 Sep 2002 21:04:49 -0700 (PDT) Cc: Robert Fenech , hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce M Simpson writes: | On Tue, Sep 03, 2002 at 09:30:43PM +0200, Robert Fenech wrote: | > I've been desperately looking for some help regarding the DP83820. Is | > anyone willing to help me pls? | | NetBSD would seem to have a driver for this. | http://www.tac.eu.org/cgi-bin/man-cgi?gsip+4 | | AUTHORS | The gsip driver was written by Jason R. Thorpe . Why not use nge(4) which now supports fiber versions: NAME nge - National Semiconductor PCI gigabit ethernet adapter driver SYNOPSIS device miibus device nge DESCRIPTION The nge driver provides support for various NICs based on the National Semiconductor DP83820 and DP83821 gigabit ethernet controller chips, including the following: Doug A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 2:34: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6622A37B400 for ; Fri, 6 Sep 2002 02:34:00 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id 6E69F43E42 for ; Fri, 6 Sep 2002 02:33:59 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 4160 invoked by uid 1031); 6 Sep 2002 09:32:16 -0000 Date: Fri, 6 Sep 2002 10:32:15 +0100 From: Bruce M Simpson To: "M. Warner Losh" Cc: freebsd-hackers@freebsd.org Subject: Re: PCMCIA questions: mapping attribute and common memory? Message-ID: <20020906093215.GI15218@spc.org> Mail-Followup-To: Bruce M Simpson , "M. Warner Losh" , freebsd-hackers@freebsd.org References: <20020905191546.GF15218@spc.org> <20020905.145936.39157187.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020905.145936.39157187.imp@bsdimp.com> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Warner, Thanks for your informative response. On Thu, Sep 05, 2002 at 02:59:36PM -0600, M. Warner Losh wrote: > You generally don't map attribute memory. With one exception (the > raylan cards), there's no hardware in the attribute memory section and > it is just used to store the cis. ... [ray(4) and xe(4)] > Those are the two worst ones to look at. Don't do what they do, as > the ray(4) hardware is weird and the xe(4) driver was written before > we could read the cis from the kernel. The particular device I'm working with is the Gemplus GPR400 PCMCIA Smart Card Reader. It has hardware registers in the attribute memory. One of these registers tells me when a card is inserted/ejected, and there are also some bits in that space which are used to handle suspending and resuming the card. What's the best way for me to do this, whilst being OLDCARD and NEWCARD compatible? (And just out of interest, is it possible to read the CIS from the kernel easily whilst still being OLDCARD friendly?) > : If so, how do I get at the resource? > : If not, how would I go about doing this myself in the driver? > > bus_alloc_resource() Ok. Say I have my first two tuples and they look like this:- Tuple #1, code = 0x1 (Common memory descriptor), length = 3 000: d4 00 ff Common memory device information: Device number 1, type Function specific, WPS = OFF Speed = 100nS, Memory block size = 512b, 1 units Tuple #2, code = 0x17 (Attribute memory descriptor), length = 3 000: 64 10 ff Attribute memory device information: Device number 1, type SRAM, WPS = OFF Speed = 100nS, Memory block size = 512b, 3 units How will these blocks be mapped when I allocate the resource? Are they coalesced into a single memory map in the order in which they appear in the CIS? Thing is, 2KB is 0x800 hex, and the register addresses I see in this Linux code I'm porting all start at 0xFA0. This would seem to indicate that a 2KB memory window is needed. [(3+1)*512]. The Linux code asks for a window size of 0x1000, which is 4KB, yet the comment says it's asking for 2KB. Bizarre. Once I've allocated the window as a resource, how would I go about accessing that memory directly? Would I need to establish a page mapping? [probe] > Ideally, you'd just match the OEM ID and vendor info of the card. > Less ideally, you'd match the strings in the CIS. So why do many pccard driver probes allocate and deallocate their card's resources? Is this merely to make sure they're available in anticipation of attach? BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 2:41:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 692DC37B400 for ; Fri, 6 Sep 2002 02:41:50 -0700 (PDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EE3C43E77 for ; Fri, 6 Sep 2002 02:41:50 -0700 (PDT) (envelope-from seva3@pacbell.net) Received: from enisey ([66.123.222.250]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0H2000A4Y48NGK@mta5.snfc21.pbi.net> for freebsd-hackers@freebsd.org; Thu, 05 Sep 2002 22:21:59 -0700 (PDT) Date: Thu, 05 Sep 2002 22:21:14 -0700 From: Seva Tonkonoh Subject: intermezzo? To: freebsd-hackers@freebsd.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, I have recently come across an old little discussion about InterMezzo. I 've got the impression that it wasn't really welcome to FreeBSD. Just curious if something similar has been done for FreeBSD, or if someone is working on such thing. I am actually looking for an MS research project topic and Intermezzo seemed to be an interesting possibility. Other suggestions would be also helpful. Thanks, Seva Tonkonoh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 2:45:22 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 568C337B400 for ; Fri, 6 Sep 2002 02:45:20 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70C5943E65 for ; Fri, 6 Sep 2002 02:45:19 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g869j8Ag018812; Fri, 6 Sep 2002 11:45:09 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Seva Tonkonoh Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: intermezzo? In-Reply-To: Your message of "Thu, 05 Sep 2002 22:21:14 PDT." Date: Fri, 06 Sep 2002 11:45:08 +0200 Message-ID: <18811.1031305508@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Seva Tonkonoh writ es: >Hi, > >I have recently come across an old little discussion about InterMezzo. >I 've got the impression that it wasn't really welcome to FreeBSD. What is it ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 2:54:19 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 342AA37B401 for ; Fri, 6 Sep 2002 02:54:17 -0700 (PDT) Received: from mail.imp.ch (mail.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADB8843E42 for ; Fri, 6 Sep 2002 02:54:15 -0700 (PDT) (envelope-from mb@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.3/8.12.3) with ESMTP id g869sEO9041521; Fri, 6 Sep 2002 11:54:14 +0200 (CEST) (envelope-from Martin.Blapp@imp.ch) Received: from levais.imp.ch (levais.imp.ch [157.161.4.66]) by nbs.imp.ch (8.12.3/8.12.3) with ESMTP id g869sE75406366; Fri, 6 Sep 2002 11:54:14 +0200 (MES) Date: Fri, 6 Sep 2002 11:59:28 +0200 (CEST) From: Martin Blapp To: Donald Becker Cc: , Subject: Re: [tulip-bug] FreeBSD Problems with dc(4) ADMtek AN985 chip In-Reply-To: Message-ID: <20020906110858.I39212-100000@levais.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi, > This technique cannot be efficiently used with mbufs in *BSD, so there > must be two different ring handling code paths: both chained > and wrapped-ring configurations. Ok > That's very likely a media selection problem, rather than a Rx > descriptor problem. Of course resetting the chip will clear a > descriptor hang, but that wouldn't be my first guess. It looks like you are right. I've seen two problems and they produced mixed results. 1.) TX underrun (FreeBSD specific) 2.) Media selection problem after small timeouts (cable problems) (Linux and FreeBSD) But why I don't see this in wind*** ? I run now this patch for two days (Enable automatically TX underrun recovery) http://www.FreeBSD.org/cgi/query-pr.cgi?pr=34236 This patch fixed the problems that all connections got dropped. After have fixed this, I still had the connection problems, but the connections were still active. It looks now that the media selection does not work all the times. If the connection goes away for just a few moments 1/10sec or faster (maybe two times fery fast) the link stays broken even if the connection is there again 100%. If the connection is interrupted more than 5/10sec the link works again. My switch does still show a active link, and ifconfig does show it as active. It looks that some recovery function does not work as expected. How does this have to behave normally. Hardware bug (chip) or software bug ? Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 4:23:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B823D37B400 for ; Fri, 6 Sep 2002 04:23:32 -0700 (PDT) Received: from scribble.fsn.hu (scribble.fsn.hu [193.224.40.95]) by mx1.FreeBSD.org (Postfix) with SMTP id E340E43E7B for ; Fri, 6 Sep 2002 04:23:30 -0700 (PDT) (envelope-from bra@fsn.hu) Received: (qmail 32035 invoked by uid 1000); 6 Sep 2002 11:23:33 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Sep 2002 11:23:33 -0000 Date: Fri, 6 Sep 2002 13:23:33 +0200 (CEST) From: Attila Nagy To: Poul-Henning Kamp Cc: Seva Tonkonoh , Subject: Re: intermezzo? In-Reply-To: <18811.1031305508@critter.freebsd.dk> Message-ID: References: <18811.1031305508@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, > >I have recently come across an old little discussion about InterMezzo. > >I 've got the impression that it wasn't really welcome to FreeBSD. > What is it ? I think he's talking about this one: What is InterMezzo? InterMezzo is a new distributed file system with a focus on high availability. InterMezzo will be suitable for replication of servers, mobile computing, managing system software on large clusters, and for maintenance of high availability clusters. http://www.inter-mezzo.org/ --------[ Free Software ISOs - ftp://ftp.fsn.hu/pub/CDROM-Images/ ]------- Attila Nagy e-mail: Attila.Nagy@fsn.hu Free Software Network (FSN.HU) phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 5: 9:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CCDB37B400 for ; Fri, 6 Sep 2002 05:09:36 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 989F543E3B for ; Fri, 6 Sep 2002 05:09:35 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0015.cvx21-bradley.dialup.earthlink.net ([209.179.192.15] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17nHv8-0006EE-00; Fri, 06 Sep 2002 05:09:06 -0700 Message-ID: <3D789A9E.A8E3B54@mindspring.com> Date: Fri, 06 Sep 2002 05:07:58 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Seva Tonkonoh Cc: freebsd-hackers@freebsd.org Subject: Re: intermezzo? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Seva Tonkonoh wrote: > I have recently come across an old little discussion about InterMezzo. > I 've got the impression that it wasn't really welcome to FreeBSD. It's illegal to distribute a binary FreeBSD distribution with GPL'ed components linked into the kernel because of clause 6 of the GPL. As long as the boot FS is not InterMezzo, and the FS is loaded as a seperately compiled module, there should be no problem with it. I kind of wish they'd LGPL'ed it, or figured some other way to not "poison pill" the code, but it still seems like it could be used. > Just curious if something similar has been done for FreeBSD, or if > someone is working on such thing. Sarnoff has done a similar implementation for FreeBSD, called MNFS, which had an integrated distributed cache coherency protocol, and was implemented for FreeBSD circa 1996. The InterMezzo paper suggest that we call te driver that implements this "a cache filter driver"; standard terminaology says we should call them "oplocks" ("opportunistic locks") or "leases". NFSv3 and NFSv4 have these features, in increasing order of integration. They note this in section 3 of their paper, but maintain their use of the "callback"/"filter driver" terminology. Maybe they wanted a patent. 8-). InterMezzo also appears to want to disable the local buffer cache, with regard to involvement in open/close (section 4). Since the VM and buffer cache are integrated in FreeBSD, this is not really possible to do. The concentration on "open/close" time is probably at fault here; you could get the same effect by caching file handles, where a real close lags some time after a close request, so that the open can be reacquired without a probem. IMO, though, this is very much an artifact of the use of Coda, and not a general optimization applicable to a correctly written distributed FS client. Some of the benchmarks are pretty bogus in the writeback caching (section 5). In particular, the mkdir/rmdir "benchmark" is a bit contrived, compared to real world usage patterns for FS's. > I am actually looking for an MS research project topic and > Intermezzo seemed to be an interesting possibility. > Other suggestions would be also helpful. You could implement this as a stacking VFS module fairly easily, beginning with the NULLFS code. The cache coherency issues in FreeBSD mean that you will be converting get/put page operations into read/write operations in your FS stacking layer (FreeBSD does not properly support stacking of all VOP's, at present), but the performance impact for the microbenchmarks in question should not really affect your FreeBSD numbers (the microbenchmarks that are describd in the paper bear little resemblance to "real work", so things that will hurt the performance of "real work", won't hurt the results of the microbenchmarks; guess you could say that was a good thing ;^)). The paper also doesn't really apply to FreeBSD; the FFS sync issues that it describes are vs. the NetBSD Coda implementation. The FFS in FreeBSD overcomes most of these issues via Soft Updates. They also could have mounted the FS async in NetBSD, to put it on a par with the speed and reliability of Ext2. All in all, it looks like an interesting thing to play with, and since you aren't going to boot from it, it's not prohibitive in the ability of people to really use the work, like an XFS or JFS GPL'ed FS that you would use as your root/boot FS would be. If you need a proof of concept, then you should block diagram out an implementation, assuming VFS stacking, and see if it can work that way (IMO, it can, bt I don't know how accurately the diagrams in the InterMezzo paper represent the interface encapsulation they imply). The most important consideration in any MS project is whether or not the project is interesting to you, and what you can get out of it (IMO). Whatever you do, do it for yourself, and if it's useful to anyone else, that's just gravy. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 6:50:50 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C2C137B400 for ; Fri, 6 Sep 2002 06:50:48 -0700 (PDT) Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by mx1.FreeBSD.org (Postfix) with SMTP id F101E43E6A for ; Fri, 6 Sep 2002 06:50:47 -0700 (PDT) (envelope-from rminnich@lanl.gov) Received: (qmail 2561098 invoked from network); 6 Sep 2002 07:50:47 -0600 Received: from xed.acl.lanl.gov (128.165.147.191) by acl.lanl.gov with SMTP; 6 Sep 2002 07:50:47 -0600 Received: (qmail 6591 invoked by uid 3499); 6 Sep 2002 07:50:46 -0600 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Sep 2002 07:50:46 -0600 Date: Fri, 6 Sep 2002 07:50:46 -0600 (MDT) From: Ronald G Minnich X-X-Sender: To: Seva Tonkonoh Cc: Subject: Re: intermezzo? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG intermezzo probably is not impossible on freebsd. I worked on the early versions and most of the hard work is done outside the kernel. It would be nice to see it on freebsd. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 6:54: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1A9637B401 for ; Fri, 6 Sep 2002 06:54:05 -0700 (PDT) Received: from mastercard.com (MCNSTL41.mastercard.com [12.22.158.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8268D43E3B for ; Fri, 6 Sep 2002 06:54:05 -0700 (PDT) (envelope-from MCNSTL41%MASTERCARD@mastercard.com) From: "MCNSTL41" X-Priority: 3 (Normal) Date: Fri, 6 Sep 2002 08:42:33 -0500 Subject: Report to Sender To: hackers Message-ID: X-MIMETrack: Serialize by Router on MCNSTL41/MASTERCARD(Release 5.0.9a |January 7, 2002) at 09/06/2002 08:54:05 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Incident Information:- Database: d:/notes/data/mail2.box Originator: hackers Recipients: hostmaster@mastercard.org, hostmaster@mastercard.com Subject: Worm Klez.E immunity Date/Time: 09/06/2002 08:42:26 AM The file attachment BORDER.exe you sent to the recipients listed above was infected with the W32/Klez.h@MM virus and was not successfully cleaned. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 7: 5:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF5CC37B401 for ; Fri, 6 Sep 2002 07:05:34 -0700 (PDT) Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 660E243E4A for ; Fri, 6 Sep 2002 07:05:34 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0015.cvx21-bradley.dialup.earthlink.net ([209.179.192.15] helo=mindspring.com) by swan.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17nJjQ-00028Q-00; Fri, 06 Sep 2002 07:05:09 -0700 Message-ID: <3D78B59F.63CEC7DF@mindspring.com> Date: Fri, 06 Sep 2002 07:03:11 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ronald G Minnich Cc: Seva Tonkonoh , freebsd-hackers@FreeBSD.ORG Subject: Re: intermezzo? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ronald G Minnich wrote: > intermezzo probably is not impossible on freebsd. I worked on the early > versions and most of the hard work is done outside the kernel. > > It would be nice to see it on freebsd. FWIW, Ron was involved in the MNFS stuff I mentioned earlier. I didn't know that he was involved in InterMezzo, though. Hi, Ron! 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 7:15:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCF1D37B406 for ; Fri, 6 Sep 2002 07:15:23 -0700 (PDT) Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by mx1.FreeBSD.org (Postfix) with SMTP id 21A5D43E65 for ; Fri, 6 Sep 2002 07:15:23 -0700 (PDT) (envelope-from rminnich@lanl.gov) Received: (qmail 2591106 invoked from network); 6 Sep 2002 08:15:22 -0600 Received: from xed.acl.lanl.gov (128.165.147.191) by acl.lanl.gov with SMTP; 6 Sep 2002 08:15:22 -0600 Received: (qmail 6736 invoked by uid 3499); 6 Sep 2002 08:15:21 -0600 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Sep 2002 08:15:21 -0600 Date: Fri, 6 Sep 2002 08:15:21 -0600 (MDT) From: Ronald G Minnich X-X-Sender: To: Terry Lambert Cc: Seva Tonkonoh , Subject: Re: intermezzo? In-Reply-To: <3D789A9E.A8E3B54@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 6 Sep 2002, Terry Lambert wrote: > Sarnoff has done a similar implementation for FreeBSD, called > MNFS, which had an integrated distributed cache coherency protocol, > and was implemented for FreeBSD circa 1996. goodness, that's me! They're pretty different however. MNFS was for distributed shared memory and was designed to ensure that mmap'ed blocks from the same file remainted consistent across a set of clients. Intermezzo is kind of like "coda done right". The intermezzo name refers to the code that layers between the VFS layer of Linux and ext2/3. OPs from the VFS layer can be redirected to user mode from the intermezzo code. I think intermezzo is doable on freebsd, it just takes time. Also, it is a module. > Maybe they wanted a patent. 8-). Fortunately Peter Braam doesn't worry about patents :-) Peter was here yesterday and tells us that intermezzo can now run over tmpfs. That's cool, I had done something like that two years ago but it was a bit of work and now it just works fine. ron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 9:20: 8 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FE3137B400 for ; Fri, 6 Sep 2002 09:20:05 -0700 (PDT) Received: from mail.eecs.harvard.edu (bowser.eecs.harvard.edu [140.247.60.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2184343E3B for ; Fri, 6 Sep 2002 09:20:05 -0700 (PDT) (envelope-from ellard@eecs.harvard.edu) Received: by mail.eecs.harvard.edu (Postfix, from userid 465) id 3850354C543; Fri, 6 Sep 2002 11:59:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id 3684C54C438 for ; Fri, 6 Sep 2002 11:59:05 -0400 (EDT) Date: Fri, 6 Sep 2002 11:59:05 -0400 (EDT) From: Dan Ellard To: hackers@FreeBSD.ORG Subject: gigabit NIC of choice? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG What's the gigabit ethernet NIC of choice these days? (I've had good experiences with the NetGear G620T, but apparently this card is no longer being sold.) I'm looking for: - Easy FreeBSD integration. - Reliability. - High performance. Thanks, -Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 10: 1:36 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 527ED37B401 for ; Fri, 6 Sep 2002 10:01:25 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id 2AC8843E42 for ; Fri, 6 Sep 2002 10:01:24 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 12830 invoked by uid 1031); 6 Sep 2002 16:59:39 -0000 Date: Fri, 6 Sep 2002 17:59:38 +0100 From: Bruce M Simpson To: "M. Warner Losh" Cc: freebsd-hackers@freebsd.org Subject: Gemplus GPR400 Message-ID: <20020906165938.GN15218@spc.org> Mail-Followup-To: Bruce M Simpson , "M. Warner Losh" , freebsd-hackers@freebsd.org References: <20020905191546.GF15218@spc.org> <20020905.145936.39157187.imp@bsdimp.com> <20020906093215.GI15218@spc.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1yeeQ81UyVL57Vl7" Content-Disposition: inline In-Reply-To: <20020906093215.GI15218@spc.org> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline It gets even better. It turns out the GPR400 doesn't support IRQ 9. Because IRQ 9 is allocated for the pcic device and muxed, the devices I put in the slot will always be allocated...irq 9. I'm using a Sony Vaio Z600, which has a Ricoh RL5C475 PCI-CardBus Bridge. So this means that pccardd can't actually configure the device. It will die, rather than give me a chance to force it into polling mode. When I try to force the IRQ for pcic0 to IRQ 3 and force ISA interrupt routing from the loader, I get a panic. I've attached the relevant dmesg output. Where do I go from here? Can I hack pccardd in any way to not baulk when it can't match free IRQs with one the card will configure to? BMS --1yeeQ81UyVL57Vl7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cardbus_panics.txt" Copyright (c) 1992-2002 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.6-STABLE #2: Wed Sep 4 18:52:52 BST 2002 root@triage.dollah.com:/usr/src/sys/compile/TRIAGE Calibrating clock(s) ... TSC clock: 794099521 Hz, i8254 clock: 1193190 Hz Timecounter "i8254" frequency 1193190 Hz CPU: Pentium III/Pentium III Xeon/Celeron (794.10-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 268369920 (262080K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x0045d000 - 0x0ffe5fff, 263753728 bytes (64393 pages) avail memory = 256819200 (250800K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f6c10 bios32: Entry = 0xfd890 (c00fd890) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x11e pnpbios: Found PnP BIOS data at 0xc00f6c40 pnpbios: Entry = f0000:b431 Rev = 1.0 pnpbios: Event flag at 400 Other BIOS signatures found: ACPI: 000f6bb0 Preloaded elf kernel "kernel" at 0xc0436000. Preloaded elf module "splash_pcx.ko" at 0xc04360a8. Preloaded elf module "vesa.ko" at 0xc043614c. Preloaded splash_image_data "/boot/splash/emily_black_640.pcx" at 0xc04361e8. Preloaded elf module "if_wi.ko" at 0xc0436248. Preloaded elf module "snd_ds1.ko" at 0xc04362e8. Preloaded elf module "snd_pcm.ko" at 0xc0436388. Preloaded elf module "uhid.ko" at 0xc0436428. Preloaded elf module "ums.ko" at 0xc04364c4. Preloaded elf module "umass.ko" at 0xc0436560. Preloaded elf module "agp.ko" at 0xc0436600. Preloaded elf module "nmdm.ko" at 0xc043669c. VESA: information block 56 45 53 41 00 02 00 01 00 01 00 00 00 00 22 00 00 01 7f 00 00 01 0b 01 00 01 21 01 00 01 2a 01 00 01 00 01 01 01 10 01 11 01 12 01 03 01 13 01 14 01 15 01 05 01 16 01 17 01 18 01 07 01 19 01 VESA: 40 mode(s) found VESA: v2.0, 8128k memory, flags:0x0, mode table:0xc03c8382 (1000022) VESA: ATI MACH64 VESA: ATI Technologies Inc. MACH64RM 01.00 Pentium Pro MTRR support enabled Creating DISK md0 md0: Malloc disk Math emulator present splash: image@0xc03c952c, size:110262 splash_pcx: image good: width = 640 height = 480 depth = 8 planes = 1 splash_pcx: considering mode 257: vi_width = 640 vi_height = 480 vi_depth = 8 vi_planes = 1 pcx_splash: selecting mode 257 splash: image decoder found: splash_pcx pci_open(1): mode 1 addr port (0x0cf8) is 0x80003904 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) Using $PIR table, 7 entries at 0xc00fdf50 apm0: on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard found-> vendor=0x8086, dev=0x7190, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[10]: type 1, range 32, base 40000000, size 24 found-> vendor=0x8086, dev=0x7191, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1 secondarybus=1 found-> vendor=0x8086, dev=0x7110, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0 secondarybus=0 found-> vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[20]: type 1, range 32, base 0000fc90, size 4 found-> vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=d, irq=9 map[20]: type 1, range 32, base 0000fca0, size 5 found-> vendor=0x8086, dev=0x7113, revid=0x03 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 map[90]: type 1, range 32, base 00001040, size 4 found-> vendor=0x104d, dev=0x8039, revid=0x02 class=0c-00-10, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base fedf7000, size 11 map[14]: type 1, range 32, base fedf7c00, size 9 found-> vendor=0x1073, dev=0x0010, revid=0x02 class=04-01-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base fedf8000, size 15 map[14]: type 1, range 32, base 0000fcc0, size 6 map[18]: type 3, range 32, base 0000fc8c, size 2 found-> vendor=0x14f1, dev=0x2443, revid=0x01 class=07-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base fede0000, size 16 map[14]: type 3, range 32, base 0000fc38, size 3 found-> vendor=0x8086, dev=0x1229, revid=0x08 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base fedf6000, size 12 map[14]: type 1, range 32, base 0000fc40, size 6 map[18]: type 1, range 32, base fec00000, size 20 found-> vendor=0x1180, dev=0x0475, revid=0x80 class=06-07-00, hdrtype=0x02, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=255 pci0: on pcib0 agp0: mem 0x40000000-0x40ffffff at device 0.0 on pci0 agp0: allocating GATT for aperture of size 16M pcib1: at device 1.0 on pci0 found-> vendor=0x1002, dev=0x4c4d, revid=0x64 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0 secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base fd000000, size 24 map[14]: type 1, range 32, base 0000e800, size 8 map[18]: type 1, range 32, base febff000, size 12 pci1: on pcib1 pci1: (vendor=0x1002, dev=0x4c4d) at 0.0 irq 9 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfc90-0xfc9f at device 7.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xfc90 ata0: mask=03 ostat0=50 ostat2=00 ata0-master: ATAPI 00 00 ata0-slave: ATAPI 00 00 ata0: mask=03 stat0=50 stat1=00 ata0-master: ATA 01 a5 ata0: devices=01 ata0: at 0x1f0 irq 14 on atapci0 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xfc98 ata1: mask=03 ostat0=00 ostat2=00 ata1-master: ATAPI 00 00 ata1-slave: ATAPI 00 00 ata1: mask=03 stat0=00 stat1=00 ata1: devices=00 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xfca0-0xfcbf irq 9 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub1: Philips Semiconductors hub, class 9/0, rev 1.10/1.10, addr 2 uhub1: 3 ports with 3 removable, self powered umass0: Sony USB Memory Stick Slot, rev 1.10/1.31, addr 3 umass0:0:0:-1: Attached to scbus0 as device 0 intpm0: port 0x1040-0x104f irq 9 at device 7.3 on pci0 intpm0: I/O mapped 1040 intpm0: intr IRQ 9 enabled revision 0 using shared irq9. smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 8000 pci0: (vendor=0x104d, dev=0x8039) at 8.0 irq 9 pcm0: port 0xfc8c-0xfc8f,0xfcc0-0xfcff mem 0xfedf8000-0xfedfffff irq 9 at device 9.0 on pci0 ds1: setmap (5000, 3de4), nseg=1, error=0 pcm0: ac97 codec id 0x414b4d02 (Asahi Kasei AK4543) pcm0: ac97 codec features headphone, 18 bit DAC, 18 bit ADC, 5 bit master volume, AKM 3D Audio pcm0: sndbuf_setmap f8c3000, 1000; 0xc15e0000 -> f8c3000 pcm0: sndbuf_setmap f8c5000, 1000; 0xc15e2000 -> f8c5000 pcm0: sndbuf_setmap f8c8000, 1000; 0xc15e5000 -> f8c8000 pcm0: sndbuf_setmap f88b000, 1000; 0xc15e8000 -> f88b000 pcm0: sndbuf_setmap f88e000, 1000; 0xc15eb000 -> f88e000 pcm0: sndbuf_setmap f890000, 1000; 0xc15ed000 -> f890000 pci0: (vendor=0x14f1, dev=0x2443) at 10.0 irq 9 fxp0: port 0xfc40-0xfc7f mem 0xfec00000-0xfecfffff,0xfedf6000-0xfedf6fff irq 9 at device 11.0 on pci0 fxp0: using memory space register mapping fxp0: Ethernet address 08:00:46:0f:2e:12 fxp0: PCI IDs: 8086 1229 104d 8084 0008 fxp0: Dynamic Standby mode is disabled inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bpf: fxp0 attached pcic0: at device 12.0 on pci0 pcic0: PCI Memory allocated: 0x88000000 pcic0: Can't route ISA CSC interrupt. panic: resource_list_release: can't find resource panic: from debugger Fatal trap 3: breakpoint instruction fault while in kernel mode instruction pointer = 0x8:0xc02864e1 stack pointer = 0x10:0xc0458c48 frame pointer = 0x10:0xc0458c50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 0 (swapper) interrupt mask = net tty bio cam panic: (fmt null) Uptime: 0s Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. Rebooting... --1yeeQ81UyVL57Vl7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 10: 1:42 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DD1C37B405 for ; Fri, 6 Sep 2002 10:01:39 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3962343E42 for ; Fri, 6 Sep 2002 10:01:39 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: from iguana.icir.org (localhost [127.0.0.1]) by iguana.icir.org (8.12.3/8.11.3) with ESMTP id g86H1bIb034836; Fri, 6 Sep 2002 10:01:37 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.12.3/8.12.3/Submit) id g86H1bjg034835; Fri, 6 Sep 2002 10:01:37 -0700 (PDT) (envelope-from rizzo) Date: Fri, 6 Sep 2002 10:01:37 -0700 From: Luigi Rizzo To: Dan Ellard Cc: hackers@FreeBSD.ORG Subject: Re: gigabit NIC of choice? Message-ID: <20020906100137.A34823@iguana.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ellard@eecs.harvard.edu on Fri, Sep 06, 2002 at 11:59:05AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 06, 2002 at 11:59:05AM -0400, Dan Ellard wrote: ... > What's the gigabit ethernet NIC of choice these days? (I've had good > experiences with the NetGear G620T, but apparently this card is no > longer being sold.) > > I'm looking for: > > - Easy FreeBSD integration. > - Reliability. > - High performance. i have had good results with the single-port Intel "em" cards They are reasonably priced too, at least the copper version. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 10: 6:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D20A437B400 for ; Fri, 6 Sep 2002 10:06:35 -0700 (PDT) Received: from mail.eecs.harvard.edu (bowser.eecs.harvard.edu [140.247.60.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8557143E65 for ; Fri, 6 Sep 2002 10:06:35 -0700 (PDT) (envelope-from ellard@eecs.harvard.edu) Received: by mail.eecs.harvard.edu (Postfix, from userid 465) id 1CF4554C7A8; Fri, 6 Sep 2002 13:06:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.eecs.harvard.edu (Postfix) with ESMTP id 1B01F54C74B; Fri, 6 Sep 2002 13:06:35 -0400 (EDT) Date: Fri, 6 Sep 2002 13:06:35 -0400 (EDT) From: Dan Ellard To: Luigi Rizzo Cc: hackers@FreeBSD.ORG Subject: Re: gigabit NIC of choice? In-Reply-To: <20020906100137.A34823@iguana.icir.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 6 Sep 2002, Luigi Rizzo wrote: > i have had good results with the single-port Intel "em" cards > They are reasonably priced too, at least the copper version. Thanks for the note. (and thanks for reminding me that I meant to ask about copper! I hope to never deal with fiber again...) -Dan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 10:33:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 01A0437B442 for ; Fri, 6 Sep 2002 10:33:17 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5DB843E77 for ; Fri, 6 Sep 2002 10:33:16 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0279.cvx22-bradley.dialup.earthlink.net ([209.179.199.24] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17nMyl-0001yL-00; Fri, 06 Sep 2002 10:33:12 -0700 Message-ID: <3D78E69C.4152CC8@mindspring.com> Date: Fri, 06 Sep 2002 10:32:12 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Ellard Cc: hackers@FreeBSD.ORG Subject: Re: gigabit NIC of choice? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dan Ellard wrote: > What's the gigabit ethernet NIC of choice these days? (I've had good > experiences with the NetGear G620T, but apparently this card is no > longer being sold.) > > I'm looking for: > > - Easy FreeBSD integration. > - Reliability. > - High performance. The Tigon II has the best performances, but that's because software people rewrote the firmware, instead of hardware engineers moonlighting as programmers. 8-) 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 10:56: 7 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A797C37B400 for ; Fri, 6 Sep 2002 10:56:01 -0700 (PDT) Received: from Millions.Ca (h24-79-52-254.sbm.shawcable.net [24.79.52.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A0F43E6A for ; Fri, 6 Sep 2002 10:56:01 -0700 (PDT) (envelope-from stacy@Millions.Ca) Received: (from uucp@localhost) by Millions.Ca (8.11.1/8.9.3) id g86Hu0557815 for ; Fri, 6 Sep 2002 11:56:00 -0600 (MDT) (envelope-from stacy@Millions.Ca) Received: from Cedar.Millions.Ca(192.168.64.8) via SMTP by mail-gw-0.millions.ca, id smtpde57813; Fri Sep 6 11:55:59 2002 Received: from millions.ca (Bonsai.Millions.Ca [192.168.64.4]) by cedar.millions.ca (8.12.2/8.12.3) with ESMTP id g86HtwcM084582 for ; Fri, 6 Sep 2002 11:55:58 -0600 (MDT) (envelope-from stacy@millions.ca) Message-ID: <3D78EC2E.6070401@millions.ca> Date: Fri, 06 Sep 2002 11:55:58 -0600 From: Stacy Millions Organization: Millions Consulting Limited User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: I climb the mountain seeking wisdom Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Any kind and learned kernel hackers out there who can spare a few cycles to help me along my learning curve? It has been a while (5+ years) since I have done any serious kernel work (SysV environment) and my copy of D&I of 4.3BSD is showing its (and my) age. At the moment, the whole area of Bus Resources is causing me greif, my panic rate is about 4 or 5 panics/hour (but I'm sure, with some coaching, I could get that to 7 or 8 :-) RTFM is an acceptable answer if accompanied by refrences, I have already read all the relevant bits I could find in http://www.freebsd.org/docs.html -stacy -- If they keep lowering education standards and raising the price of gasoline, there are going to be a lot of stupid people walking around. Stacy Millions stacy@millions.ca Millions Consulting Limited To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 10:59: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 648E637B400 for ; Fri, 6 Sep 2002 10:59:06 -0700 (PDT) Received: from mail.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id E989243E72 for ; Fri, 6 Sep 2002 10:59:05 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24511 invoked from network); 6 Sep 2002 17:59:04 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 6 Sep 2002 17:59:04 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g86HwwBv015392; Fri, 6 Sep 2002 13:58:59 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3D78EC2E.6070401@millions.ca> Date: Fri, 06 Sep 2002 13:58:58 -0400 (EDT) From: John Baldwin To: Stacy Millions Subject: RE: I climb the mountain seeking wisdom Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 06-Sep-2002 Stacy Millions wrote: > Any kind and learned kernel hackers out there who can spare a few > cycles to help me along my learning curve? > > It has been a while (5+ years) since I have done any serious kernel > work (SysV environment) and my copy of D&I of 4.3BSD is showing its > (and my) age. > > At the moment, the whole area of Bus Resources is causing me greif, > my panic rate is about 4 or 5 panics/hour (but I'm sure, with some > coaching, I could get that to 7 or 8 :-) What kind of panics? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 11:10:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71F6B37B400 for ; Fri, 6 Sep 2002 11:10:05 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id BF2D643E42 for ; Fri, 6 Sep 2002 11:10:04 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 11216 invoked by uid 1031); 6 Sep 2002 18:08:19 -0000 Date: Fri, 6 Sep 2002 19:08:18 +0100 From: Bruce M Simpson To: "M. Warner Losh" Cc: freebsd-hackers@freebsd.org Subject: Re: Gemplus GPR400 Message-ID: <20020906180818.GO15218@spc.org> Mail-Followup-To: Bruce M Simpson , "M. Warner Losh" , freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I've booted into Windows (which appears to use ACPI, but I have the BIOS configuring and allocating resources). Windows uses the following for the Cardbus controller: irq 9, db000-dbfff (presumably the memory window with the GPR400 inserted), and 0x3e0-0x3e1 for pcmcia configuration. The GPR400 ends up getting 0x240-0x25F with IRQ *7* under Win2k. Why does the pcic0 device under -STABLE wind up assigning everything 9? Is this a stupid question? Do I get a biscuit? BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 11:18:45 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D012F37B400 for ; Fri, 6 Sep 2002 11:18:42 -0700 (PDT) Received: from spork.pantherdragon.org (spork.pantherdragon.org [206.29.168.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ACBB43E6E for ; Fri, 6 Sep 2002 11:18:42 -0700 (PDT) (envelope-from dmp@pantherdragon.org) Received: from sparx.techno.pagans (evrtwa1-ar10-4-61-252-069.evrtwa1.dsl-verizon.net [4.61.252.69]) by spork.pantherdragon.org (Postfix) with ESMTP id B58FD10091; Fri, 6 Sep 2002 11:18:41 -0700 (PDT) Received: from pantherdragon.org (speck.techno.pagans [172.21.42.2]) by sparx.techno.pagans (Postfix) with ESMTP id D91B4AA92; Fri, 6 Sep 2002 11:18:39 -0700 (PDT) Message-ID: <3D78F17F.5BE2499B@pantherdragon.org> Date: Fri, 06 Sep 2002 11:18:39 -0700 From: Darren Pilgrim X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Dan Ellard , hackers@FreeBSD.ORG Subject: Re: gigabit NIC of choice? References: <3D78E69C.4152CC8@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > Dan Ellard wrote: > > What's the gigabit ethernet NIC of choice these days? (I've had good > > experiences with the NetGear G620T, but apparently this card is no > > longer being sold.) > > The Tigon II has the best performances, but that's because > software people rewrote the firmware, instead of hardware > engineers moonlighting as programmers. 8-) 8-). I recall from a while back that gigabit cards have "relatively" large caches on them, correct? How does the size of the cache impact performance, and what is considered a sufficient cache size? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 11:23:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98CE937B400; Fri, 6 Sep 2002 11:23:24 -0700 (PDT) Received: from Millions.Ca (h24-79-52-254.sbm.shawcable.net [24.79.52.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCF0443E72; Fri, 6 Sep 2002 11:23:23 -0700 (PDT) (envelope-from stacy@Millions.Ca) Received: (from uucp@localhost) by Millions.Ca (8.11.1/8.9.3) id g86INNr57903; Fri, 6 Sep 2002 12:23:23 -0600 (MDT) (envelope-from stacy@Millions.Ca) Received: from Cedar.Millions.Ca(192.168.64.8) via SMTP by mail-gw-0.millions.ca, id smtpdj57894; Fri Sep 6 12:23:15 2002 Received: from millions.ca (Bonsai.Millions.Ca [192.168.64.4]) by cedar.millions.ca (8.12.2/8.12.3) with ESMTP id g86INEcM084637; Fri, 6 Sep 2002 12:23:14 -0600 (MDT) (envelope-from stacy@millions.ca) Message-ID: <3D78F291.8010005@millions.ca> Date: Fri, 06 Sep 2002 12:23:13 -0600 From: Stacy Millions Organization: Millions Consulting Limited User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin Cc: hackers@FreeBSD.ORG Subject: Re: I climb the mountain seeking wisdom References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: > On 06-Sep-2002 Stacy Millions wrote: >>At the moment, the whole area of Bus Resources is causing me greif, >>my panic rate is about 4 or 5 panics/hour (but I'm sure, with some >>coaching, I could get that to 7 or 8 :-) > > > What kind of panics? > Page fault while in kernel mode.... unfortunately, ddb hangs so I don't get a core file. -stacy -- If they keep lowering education standards and raising the price of gasoline, there are going to be a lot of stupid people walking around. Stacy Millions stacy@millions.ca Millions Consulting Limited To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 11:43:28 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD81037B400 for ; Fri, 6 Sep 2002 11:43:26 -0700 (PDT) Received: from relay02.cablecom.net (relay02.cablecom.net [62.2.33.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id E95FD43E6E for ; Fri, 6 Sep 2002 11:43:25 -0700 (PDT) (envelope-from hanspeter_roth@hotmail.com) Received: from gicco.cablecom.ch (dclient80-218-73-118.hispeed.ch [80.218.73.118]) by relay02.cablecom.net (8.12.5/8.12.5/SOL/AWF/MXRELAY/20020820) with ESMTP id g86IhOWs067913 for ; Fri, 6 Sep 2002 20:43:24 +0200 (CEST) (envelope-from hanspeter_roth@hotmail.com) Received: (from idefix@localhost) by gicco.cablecom.ch (8.11.6/8.11.6) id g86IhOh01282 for freebsd-hackers@freebsd.org; Fri, 6 Sep 2002 20:43:24 +0200 (CEST) (envelope-from hanspeter_roth@hotmail.com) Date: Fri, 6 Sep 2002 20:43:24 +0200 From: Hanspeter Roth To: freebsd-hackers@freebsd.org Subject: interrupting the remote kernel Message-ID: <20020906204324.A1258@gicco.cablecom.ch> Reply-To: freebsd-hackers@freebsd.org Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello, I have BREAK_TO_DEBUGGER, DDB and no DDB_UNATTENDED on the target kernel and remotebreak = 1 on the remote gdb. So I'm expecting pressing ctl-C in the remote gdb should interrupt the remote kernel as if it had encountered a breakpoint. Is my expectation right? Nothing happens when pressing ctl-C once. Pressing it twice just gives me the option to detach gdb. How can I interrupt the remote kernel without breakpoints? I'm trying to locate kernel hangings. Is it possible with this approach? -Hanspeter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 12: 9:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37B7637B400 for ; Fri, 6 Sep 2002 12:09:32 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCAB943E42 for ; Fri, 6 Sep 2002 12:09:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0483.cvx22-bradley.dialup.earthlink.net ([209.179.199.228] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17nOTv-0003pq-00; Fri, 06 Sep 2002 12:09:28 -0700 Message-ID: <3D78FD1E.EAA7ABD7@mindspring.com> Date: Fri, 06 Sep 2002 12:08:14 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Darren Pilgrim Cc: Dan Ellard , hackers@FreeBSD.ORG Subject: Re: gigabit NIC of choice? References: <3D78E69C.4152CC8@mindspring.com> <3D78F17F.5BE2499B@pantherdragon.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Darren Pilgrim wrote: > Terry Lambert wrote: > > Dan Ellard wrote: > > > What's the gigabit ethernet NIC of choice these days? (I've had good > > > experiences with the NetGear G620T, but apparently this card is no > > > longer being sold.) > > > > The Tigon II has the best performances, but that's because > > software people rewrote the firmware, instead of hardware > > engineers moonlighting as programmers. 8-) 8-). > > I recall from a while back that gigabit cards have "relatively" large > caches on them, correct? How does the size of the cache impact > performance, and what is considered a sufficient cache size? The best advice I have for you is to read the source code for the drivers, specifically any commentary by Bill Paul up top; he tells it like it is, with regard to the hardware. In general, cards with DMA engines that require better than two byte alignment require that the mbufs be copied again for transmit. Also, in general, the more queue descriptors, the better, since they limit the number of packets pending input or output that you can have outstanding simultaneously. Controllers that can't do scatter/gather are also problematic, because they mean you have to allocate a seperate buffer area out of memory and copy outbound data into thue buffer instead of scattering, and copy from the buffer to mbufs on the receive (gather). The smaller the amount of memory on the card, the worse things are, as well, because it limits the amount of data you can have outstanding, as well, which limits your throuput. Bad cards are also not capable of software interrupt coelescing (this was one of my contributions). Basically, what this means is that a card will not DMA, or does not have a "modified" register, or does not update it, while an interuppt is being processed (e.g. after the interrupt is raised in hardware, and has not yet been ACKed). The effect of this is that you can't poll at the end of the interrupt handler for new data, only exitting the handler when there is no new data to process (10 to 15% performance inmprovement, by my benchmarks). Bad cards will also have smaller on-chip buffers (as opposed to on-card buffers). For example, there are a number of cards that supposedly support both "jumbograms" and TCP checksum offloading, but have only 8K of space. A "jumbogram" is 9K, so when using jumbograms, it's impossible to offload checksums to the hardware. There are cards that supposedly support checksumming, but use the buggy incremental checksum update algorithm (two's complement vs. one's complement arithmatic), and will screw up the TCP checksum, yielding 0xfffe instead of 0x0000 after summing, because they don't correctly handle negative zero (there is an RFC update on this). A really good card will allow you to align card buffers to host page boundaries, which can dignificantly speed up I/O. This is what I was referring to when I said there was a rewritten firmware for the Tigon II. The manufacturer won't reall share sufficient information for this interface to be implemented on the Tigon III. Basically, it eliminates another copy. The absolute worst one (according to Bill Paul) is the RealTek 8129/8139. See the comments in /usr/src/sys/pci/if_rl.c. Mostly, if you go by the comments in the drivers, you'll get a feel for what's done right and what's done wrong from a host interface perspective by the card manufacturer. As to your cache question... the size of the cache is the pool size. If you look at this as a queueing theory problem, then amount of buffer space translates directly into how much it's willing to tolerate delays in servicing interrupts -- pool retention time. Above a certain size, and it really won't effect your ability to shove data through it because there will be more and more free space available. Unless you are going card-to-card (unlikely; most firmware doesn't support the necessary ability to do incremental header rewriting, and flow monitoring, so that you can mark flows without in-band data that needs to be rewritten e.g. text IP addresses in FTP "port" commands, etc.), you will always end up with a certain amount of buffer space free, because the limiting factor is going to be your ability to shovel data over the PCI bus from the disk to main memory and back over the same bus to the network card. So my flip answer seems flip, but to get the best overall performance, you should use a Tigon II with the FreeBSD specific firmware, and the zero copy TCP patches that need the firmware patches. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 12:16:30 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C810137B400 for ; Fri, 6 Sep 2002 12:16:28 -0700 (PDT) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61DDD43E6A for ; Fri, 6 Sep 2002 12:16:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0483.cvx22-bradley.dialup.earthlink.net ([209.179.199.228] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 4.10) id 17nOaf-0000Pg-00; Fri, 06 Sep 2002 12:16:25 -0700 Message-ID: <3D78FEBE.3E82D458@mindspring.com> Date: Fri, 06 Sep 2002 12:15:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Darren Pilgrim , Dan Ellard , hackers@FreeBSD.ORG Subject: Re: gigabit NIC of choice? References: <3D78E69C.4152CC8@mindspring.com> <3D78F17F.5BE2499B@pantherdragon.org> <3D78FD1E.EAA7ABD7@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert wrote: > > > The Tigon II has the best performances, but that's because > > > software people rewrote the firmware, instead of hardware > > > engineers moonlighting as programmers. 8-) 8-). References: http://people.freebsd.org/~ken/zero_copy/ -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 12:20:15 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8FED37B400 for ; Fri, 6 Sep 2002 12:20:08 -0700 (PDT) Received: from sccrmhc01.attbi.com (sccrmhc01.attbi.com [204.127.202.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F27843E65 for ; Fri, 6 Sep 2002 12:20:08 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc01.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020906192007.BCMA9751.sccrmhc01.attbi.com@InterJet.elischer.org> for ; Fri, 6 Sep 2002 19:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA42767 for ; Fri, 6 Sep 2002 12:11:28 -0700 (PDT) Date: Fri, 6 Sep 2002 12:11:28 -0700 (PDT) From: Julian Elischer To: freebsd-hackers@freebsd.org Subject: Re: interrupting the remote kernel In-Reply-To: <20020906204324.A1258@gicco.cablecom.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG hit CTL_ALT_ESC on it's keyboard... or do: sysctl debug.enter_debugger=gdb On Fri, 6 Sep 2002, Hanspeter Roth wrote: > Hello, > > I have BREAK_TO_DEBUGGER, DDB and no DDB_UNATTENDED on the target > kernel and remotebreak = 1 on the remote gdb. So I'm expecting > pressing ctl-C in the remote gdb should interrupt the remote kernel > as if it had encountered a breakpoint. Is my expectation right? > > Nothing happens when pressing ctl-C once. Pressing it twice just > gives me the option to detach gdb. > > How can I interrupt the remote kernel without breakpoints? > I'm trying to locate kernel hangings. Is it possible with this > approach? > > -Hanspeter > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 12:31:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76CF137B401 for ; Fri, 6 Sep 2002 12:31:46 -0700 (PDT) Received: from spork.pantherdragon.org (spork.pantherdragon.org [206.29.168.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8E6B43E7B for ; Fri, 6 Sep 2002 12:31:45 -0700 (PDT) (envelope-from dmp@pantherdragon.org) Received: from sparx.techno.pagans (evrtwa1-ar10-4-61-252-069.evrtwa1.dsl-verizon.net [4.61.252.69]) by spork.pantherdragon.org (Postfix) with ESMTP id 009F710091; Fri, 6 Sep 2002 12:31:44 -0700 (PDT) Received: from pantherdragon.org (speck.techno.pagans [172.21.42.2]) by sparx.techno.pagans (Postfix) with ESMTP id 15012AA92; Fri, 6 Sep 2002 12:31:43 -0700 (PDT) Message-ID: <3D79029E.ED8020EF@pantherdragon.org> Date: Fri, 06 Sep 2002 12:31:42 -0700 From: Darren Pilgrim X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry Lambert Cc: Dan Ellard , hackers@FreeBSD.ORG Subject: Re: gigabit NIC of choice? References: <3D78E69C.4152CC8@mindspring.com> <3D78F17F.5BE2499B@pantherdragon.org> <3D78FD1E.EAA7ABD7@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thank you! It was fun to watch questions come up and get shot down while reading the same email. Now if you'll excuse me, I need to go use the source, Terry. Terry Lambert wrote: > Darren Pilgrim wrote: > > Terry Lambert wrote: > > > Dan Ellard wrote: > > > > What's the gigabit ethernet NIC of choice these days? (I've had good > > > > experiences with the NetGear G620T, but apparently this card is no > > > > longer being sold.) > > > > > > The Tigon II has the best performances, but that's because > > > software people rewrote the firmware, instead of hardware > > > engineers moonlighting as programmers. 8-) 8-). > > > > I recall from a while back that gigabit cards have "relatively" large > > caches on them, correct? How does the size of the cache impact > > performance, and what is considered a sufficient cache size? > > The best advice I have for you is to read the source code for > the drivers, specifically any commentary by Bill Paul up top; > he tells it like it is, with regard to the hardware. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 12:52:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFE3237B409 for ; Fri, 6 Sep 2002 12:52:36 -0700 (PDT) Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB75543E42 for ; Fri, 6 Sep 2002 12:52:35 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: from panzer.kdm.org (localhost [127.0.0.1]) by panzer.kdm.org (8.12.5/8.12.5) with ESMTP id g86JqUKD019160; Fri, 6 Sep 2002 13:52:30 -0600 (MDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.12.5/8.12.5/Submit) id g86JqUYw019159; Fri, 6 Sep 2002 13:52:30 -0600 (MDT) (envelope-from ken) Date: Fri, 6 Sep 2002 13:52:30 -0600 From: "Kenneth D. Merry" To: Terry Lambert Cc: Dan Ellard , hackers@FreeBSD.ORG Subject: Re: gigabit NIC of choice? Message-ID: <20020906135229.A18971@panzer.kdm.org> References: <3D78E69C.4152CC8@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D78E69C.4152CC8@mindspring.com>; from tlambert2@mindspring.com on Fri, Sep 06, 2002 at 10:32:12AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 06, 2002 at 10:32:12 -0700, Terry Lambert wrote: > Dan Ellard wrote: > > What's the gigabit ethernet NIC of choice these days? (I've had good > > experiences with the NetGear G620T, but apparently this card is no > > longer being sold.) > > > > I'm looking for: > > > > - Easy FreeBSD integration. > > - Reliability. > > - High performance. > > The Tigon II has the best performances, but that's because > software people rewrote the firmware, instead of hardware > engineers moonlighting as programmers. 8-) 8-). You'll get good performance with the Tigon II with jumbo frames under -current with ZERO_COPY_SOCKETS and TI_JUMBO_HDRSPLIT turned on. Note that "good performance" == "lower CPU utilization" here, although it is difficult to see any improvement in -current with SMP enabled, and the improvement isn't as large in UP mode as it used to be. You can easily get wire rates with jumbo frames with a Tigon II without zero copy, given a reasonably fast machine. (At least on -stable. Reasonably fast == 1GHz Pentium III, 64 bit PCI.) With 1500 byte frames, though, the Tigon II won't perform as well as some other controllers. For most folks, performance with 1500 byte frames is what matters, since you usually need a jumbo-capable gigabit switch to take advantage of jumbo frames in anything more than a point to point environment. The modifications I made to the Tigon firmware (the ones that are in FreeBSD) are actually relatively minor. The main "trick" is to make sure that the header is in its own scatter/gather element, so the payload will be page aligned. (Assuming the second and subsequent scatter/gather elements are page aligned.) So if your workload consists of jumbo frames for the most part, and receive performance is important, I would suggest a Tigon II-based board, like the GA620T, if you can find one. (Obviously that's getting more and more difficult nowadays.) Otherwise, I would suggest another card with better performance with 1500 byte frames. (I haven't done any tests with other boards, so I can't make specific recommendations.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 13: 0:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D0FD37B400 for ; Fri, 6 Sep 2002 13:00:36 -0700 (PDT) Received: from relay03.cablecom.net (relay03.cablecom.net [62.2.33.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id D605A43E4A for ; Fri, 6 Sep 2002 13:00:34 -0700 (PDT) (envelope-from hanspeter_roth@hotmail.com) Received: from gicco.cablecom.ch (dclient80-218-73-118.hispeed.ch [80.218.73.118]) by relay03.cablecom.net (8.12.5/8.12.5/SOL/AWF/MXRELAY/20020820) with ESMTP id g86K0XMO046523 for ; Fri, 6 Sep 2002 22:00:33 +0200 (CEST) (envelope-from hanspeter_roth@hotmail.com) Received: (from idefix@localhost) by gicco.cablecom.ch (8.11.6/8.11.6) id g86K0XZ01904 for freebsd-hackers@FreeBSD.ORG; Fri, 6 Sep 2002 22:00:33 +0200 (CEST) (envelope-from hanspeter_roth@hotmail.com) Date: Fri, 6 Sep 2002 22:00:33 +0200 From: Hanspeter Roth To: freebsd-hackers@FreeBSD.ORG Subject: Re: interrupting the remote kernel Message-ID: <20020906220033.A1830@gicco.cablecom.ch> Reply-To: freebsd-hackers@FreeBSD.ORG Mail-Followup-To: freebsd-hackers@FreeBSD.ORG References: <20020906204324.A1258@gicco.cablecom.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from julian@elischer.org on Fri, Sep 06, 2002 at 12:11:28PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sep 06 at 12:11, Julian Elischer spoke: > hit CTL_ALT_ESC on it's keyboard... Doing this on the remote host (running gdb) tells me `No debugger in kernel'. Doing this on the target host passes control to the remote gdb. But I want to pass control to the remote debugger by issuing the interrupt command on the _remote_ host (in gdb). > or do: > sysctl debug.enter_debugger=gdb Doing this on the target host also passes control to the remote gdb. But I want to be able to pass control to the debugger when the target kernel `hangs', that is when no `ctl-alt-f1', `ctl-alt-del' has any effect. I thought that remotebreak on the remote gdb should allow me this. But it seems to be something else... -Hanspeter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 13:30:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E511637B400 for ; Fri, 6 Sep 2002 13:30:30 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-165-226-88.dsl.lsan03.pacbell.net [64.165.226.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id AED6243E75 for ; Fri, 6 Sep 2002 13:30:27 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id D460E66D7A; Fri, 6 Sep 2002 13:30:26 -0700 (PDT) Date: Fri, 6 Sep 2002 13:30:26 -0700 From: Kris Kennaway To: Peter Wemm Cc: Darren Pilgrim , Matthew Dillon , Dan Nelson , Terry Lambert , Jason Andresen , Dmitry Morozovsky , hackers@FreeBSD.ORG Subject: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build) Message-ID: <20020906203026.GA78157@xor.obsecurity.org> References: <3D50664F.71603B49@pantherdragon.org> <20020807015511.A1A092A7D6@canning.wemm.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <20020807015511.A1A092A7D6@canning.wemm.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 06, 2002 at 06:55:11PM -0700, Peter Wemm wrote: > `-mcpu=3DCPU-TYPE' > Tune to CPU-TYPE everything applicable about the generated code, > except for the ABI and the set of available instructions. The > choices for CPU-TYPE are `i386', `i486', `i586', `i686', > `pentium', `pentium-mmx', `pentiumpro', `pentium2', `pentium3', > `pentium4', `k6', `k6-2', `k6-3', `athlon', `athlon-tbird', > `athlon-4', `athlon-xp' and `athlon-mp'. >=20 > You can also add -msse, -msse2, -m3dnow to use those extensions. It would > appear that our bsd.cpu.mk file is out of date and is missing the newer > cpu types. How about the following patch (I've only tested 'pentium3'): Index: share/mk/bsd.cpu.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/home/ncvs/src/share/mk/bsd.cpu.mk,v retrieving revision 1.16 diff -u -r1.16 bsd.cpu.mk --- share/mk/bsd.cpu.mk 2 Aug 2002 18:04:22 -0000 1.16 +++ share/mk/bsd.cpu.mk 6 Sep 2002 20:25:46 -0000 @@ -28,8 +28,8 @@ CPUTYPE =3D i686 . elif ${CPUTYPE} =3D=3D "pentium" CPUTYPE =3D i586 -. elif ${CPUTYPE} =3D=3D "athlon" -CPUTYPE =3D k7 +. elif ${CPUTYPE} =3D=3D "k7" +CPUTYPE =3D athlon . endif . endif =20 @@ -42,20 +42,30 @@ # http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html =20 . if ${MACHINE_ARCH} =3D=3D "i386" -. if ${CPUTYPE} =3D=3D "k7" +. if ${CPUTYPE} =3D=3D "athlon-mp" +_CPUCFLAGS =3D -march=3Dathlon-mp +. elif ${CPUTYPE} =3D=3D "athlon-xp" +_CPUCFLAGS =3D -march=3Dathlon-xp +. elif ${CPUTYPE} =3D=3D "athlon-4" +_CPUCFLAGS =3D -march=3Dathlon-4 +. elif ${CPUTYPE} =3D=3D "athlon-tbird" +_CPUCFLAGS =3D -march=3Dathlon-tbird +. elif ${CPUTYPE} =3D=3D "athlon" _CPUCFLAGS =3D -march=3Dathlon +. elif ${CPUTYPE} =3D=3D "k6-3" +_CPUCFLAGS =3D -march=3Dk6-3 . elif ${CPUTYPE} =3D=3D "k6-2" -_CPUCFLAGS =3D -march=3Dk6 +_CPUCFLAGS =3D -march=3Dk6-2 . elif ${CPUTYPE} =3D=3D "k6" _CPUCFLAGS =3D -march=3Dk6 . elif ${CPUTYPE} =3D=3D "k5" _CPUCFLAGS =3D -march=3Dpentium . elif ${CPUTYPE} =3D=3D "p4" -_CPUCFLAGS =3D -march=3Dpentiumpro +_CPUCFLAGS =3D -march=3Dpentium4 . elif ${CPUTYPE} =3D=3D "p3" -_CPUCFLAGS =3D -march=3Dpentiumpro +_CPUCFLAGS =3D -march=3Dpentium3 . elif ${CPUTYPE} =3D=3D "p2" -_CPUCFLAGS =3D -march=3Dpentiumpro +_CPUCFLAGS =3D -march=3Dpentium2 . elif ${CPUTYPE} =3D=3D "i686" _CPUCFLAGS =3D -march=3Dpentiumpro . elif ${CPUTYPE} =3D=3D "i586/mmx" Index: share/examples/etc/make.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/home/ncvs/src/share/examples/etc/make.conf,v retrieving revision 1.198 diff -u -r1.198 make.conf --- share/examples/etc/make.conf 2 Aug 2002 18:04:22 -0000 1.198 +++ share/examples/etc/make.conf 6 Sep 2002 20:25:19 -0000 @@ -24,7 +24,7 @@ # NO_CPU_CFLAGS variable below. # Currently the following CPU types are recognized: # Intel x86 architecture: -# (AMD CPUs) k7 k6-2 k6 k5 +# (AMD CPUs) athlon-mp athlon-xp athlon-4 athlon-tbird athlon k6-3 k= 6-2 k6 k5 # (Intel CPUs) p4 p3 p2 i686 i586/mmx i586 i486 i386 # Alpha/AXP architecture: ev6 pca56 ev56 ev5 ev45 ev4 # Intel ia64 architecture: itanium --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9eRBhWry0BWjoQKURAg2NAJ0ZpUWXoWQmXdPEX/2dgNONuwrSWwCg3ii8 Tt16zWIfWLcis7ai9VVin0A= =fvmy -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 13:31:23 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09B2837B400 for ; Fri, 6 Sep 2002 13:31:20 -0700 (PDT) Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52E6343E42 for ; Fri, 6 Sep 2002 13:31:19 -0700 (PDT) (envelope-from wayne@staff.msen.com) Received: from manor.msen.com (wayne@localhost [127.0.0.1]) by manor.msen.com (8.9.3/8.9.3) with ESMTP id QAA05990 for ; Fri, 6 Sep 2002 16:31:18 -0400 (EDT) (envelope-from wayne@manor.msen.com) Message-Id: <200209062031.QAA05990@manor.msen.com> To: hackers@freebsd.org Subject: Excessive swap usage w/ 4.6 Date: Fri, 06 Sep 2002 16:31:18 -0400 From: "Michael R. Wayne" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG After having moved servers from 4.3 and 4.5 to 4.6, we are noticing that swap indicates much higher usage. Today, one of our squid cache servers hit (and stayed at) 50% swap utilization so I decided to do some digging. This machine has 512 MB physical RAM in it and is running FreeBSD 4.5-RELEASE-p7 Here's a ps with some cruft removed and columns widened for readability. > ps -axel CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 -18 0 0 0 sched DLs ?? 0:00.00 (swapper) 0 10 0 544 116 wait ILs ?? 0:00.31 /sbin/init -- 0 -18 0 0 0 psleep DL ?? 5:30.16 (pagedaemon) 0 18 0 0 0 psleep DL ?? 0:00.04 (vmdaemon) 0 -18 0 0 0 psleep DL ?? 0:33.61 (bufdaemon) 0 -2 0 0 0 vlruwt DL ?? 0:29.52 (vnlru) 0 18 0 0 0 syncer DL ?? 29:36.89 (syncer) 0 2 0 948 340 select Ss ?? 0:15.27 /usr/sbin/syslogd -s 0 2 0 1300 352 select Ss ?? 3:52.69 ntpd -p /var/run/ntpd.pid 0 2 0 1064 560 select Is ?? 0:00.18 /usr/sbin/inetd -wW 0 10 0 984 216 nanslp Is ?? 0:15.08 /usr/sbin/cron 28 2 0 2136 264 select Is ?? 3:00.12 /usr/local/sbin/sshd 0 10 0 2940 0 wait IWs ?? 0:00.00 () /usr/local/sbin/squid 4 2 0 398380 381916 poll S ?? 286:58.56 (squid) (squid) 0 -6 0 860 176 piperd Ss ?? 1:35.35 (unlinkd) (unlinkd) 0 2 0 4792 512 select Ss ?? 0:01.48 sshd: 0 2 0 2732 1920 select Ss ?? 0:02.73 /usr/local/sbin/gated 0 2 0 2096 1464 select Ss ?? 0:00.08 /usr/local/sbin/httpd 0 2 0 2504 1660 accept I ?? 0:00.01 /usr/local/sbin/httpd 0 2 0 2512 1668 accept I ?? 0:00.01 /usr/local/sbin/httpd 0 18 0 1584 820 pause Ss p0 0:00.51 SSH_CLIENT= 0 28 0 416 172 - R+ p0 0:00.00 SSH_CLIENT= 0 3 0 948 528 ttyin Is+ v0 0:00.00 /usr/libexec/getty Pc ttyv0 0 3 0 948 524 ttyin Is+ v1 0:00.00 /usr/libexec/getty Pc ttyv1 ======= ======= Totals 427,688 393,208 -393,208 ======= 34,480 So, swap usage should be about this much. But: > pstat -s Device 1K-blocks Used Avail Capacity Type /dev/ad0s1b 614272 304792 309480 50% Interleaved This seems very excessive as well as unjustified. Is there some way I can find out if I have a "swap leak" or some other way to figure out what is going on? As I mentioned, we noticed a significant increase in swap usage on many servers between 4.3 or 4.5 and 4.6 /\/\ \/\/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 14:23: 2 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5264937B400 for ; Fri, 6 Sep 2002 14:23:00 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 912AC43E4A for ; Fri, 6 Sep 2002 14:22:59 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.5/8.12.5) id g86LMqH6008334; Fri, 6 Sep 2002 16:22:52 -0500 (CDT) (envelope-from dan) Date: Fri, 6 Sep 2002 16:22:52 -0500 From: Dan Nelson To: Kris Kennaway Cc: Peter Wemm , Darren Pilgrim , Matthew Dillon , Terry Lambert , Jason Andresen , Dmitry Morozovsky , hackers@FreeBSD.ORG Subject: Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build) Message-ID: <20020906212252.GB2767@dan.emsphone.com> References: <3D50664F.71603B49@pantherdragon.org> <20020807015511.A1A092A7D6@canning.wemm.org> <20020906203026.GA78157@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020906203026.GA78157@xor.obsecurity.org> X-OS: FreeBSD 5.0-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the last episode (Sep 06), Kris Kennaway said: > How about the following patch (I've only tested 'pentium3'): > > Index: share/mk/bsd.cpu.mk I've been using a similar patch ever since 3.* went into the tree with no problems. Haven't benchmarked the difference between pentiumpro and the other options, either, though. -- Dan Nelson dnelson@allantgroup.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 17:17: 9 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A036637B400 for ; Fri, 6 Sep 2002 17:17:06 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 3D58543E6A for ; Fri, 6 Sep 2002 17:17:06 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 5986 invoked by uid 1000); 7 Sep 2002 00:17:07 -0000 Date: Fri, 6 Sep 2002 17:17:07 -0700 (PDT) From: Nate Lawson To: freebsd-hackers@FreeBSD.ORG Subject: Re: interrupting the remote kernel In-Reply-To: <20020906220033.A1830@gicco.cablecom.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 6 Sep 2002, Hanspeter Roth wrote: > On Sep 06 at 12:11, Julian Elischer spoke: > > > hit CTL_ALT_ESC on it's keyboard... > > Doing this on the remote host (running gdb) tells me `No debugger in > kernel'. > Doing this on the target host passes control to the remote gdb. Like it should. Julian's suggestions were both for the target host. > But I want to pass control to the remote debugger by issuing > the interrupt command on the _remote_ host (in gdb). You can do this by connecting a second serial cable for a console between your host and target or by using the remotechat option and a single cable. Once you have the serial console, option ALT_BREAK_TO_DEBUGGER allows you to initiate a break using your terminal emulator's "send break" command. > But I want to be able to pass control to the debugger when the > target kernel `hangs', that is when no `ctl-alt-f1', `ctl-alt-del' > has any effect. If the hang is not a system hang, the console break will have an effect. But if the kernel is so hung that the keyboard doesn't work, the remote serial console will not do you any better. In this case you need a box with a real console (i.e. Sun). -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 17:32:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D53CA37B401 for ; Fri, 6 Sep 2002 17:32:27 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 58BB843E6E for ; Fri, 6 Sep 2002 17:32:27 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 6023 invoked by uid 1000); 7 Sep 2002 00:32:29 -0000 Date: Fri, 6 Sep 2002 17:32:29 -0700 (PDT) From: Nate Lawson To: Bruce M Simpson Cc: hackers@freebsd.org, scsi@freebsd.org Subject: Re: New scsi_target code In-Reply-To: <20020905092426.GA9129@spc.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 5 Sep 2002, Bruce M Simpson wrote: > On Thu, Sep 05, 2002 at 01:54:08AM -0700, Nate Lawson wrote: > > I have rewritten the scsi_target driver and usermode client with a much > > simpler model suggested by Justin Gibbs. The kernel driver receives > > This sounds like excellent work and I can't wait to check it out further. > Whilst looking into the problem of USB->ATA bridge support I was recently > faced with the problem of writing various ATA->SCSI command translations, > which involved emulating a SCSI device, so I imagine your code should be > very useful. Possibly. I have updated the version online with a patch for -current. It builds and runs but panics in read/write. I'll look into the issues with -current over the weekend. I'm very interested in comments and testing on -stable to help update the general architecture and stability. Thanks, -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 17:34:33 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4001137B400 for ; Fri, 6 Sep 2002 17:34:31 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id 87C4343E75 for ; Fri, 6 Sep 2002 17:34:30 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 1050 invoked by uid 1031); 7 Sep 2002 00:32:42 -0000 Date: Sat, 7 Sep 2002 01:32:42 +0100 From: Bruce M Simpson To: "M. Warner Losh" Cc: freebsd-hackers@freebsd.org Subject: NEWCARD in -STABLE Message-ID: <20020907003242.GP15218@spc.org> Mail-Followup-To: Bruce M Simpson , "M. Warner Losh" , freebsd-hackers@freebsd.org References: <20020906180818.GO15218@spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020906180818.GO15218@spc.org> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I had a thought. Perhaps this situation makes me an ideal candidate for being a guinea pig for NEWCARD in -STABLE? Just a thought. If you have diffs, bring it on. If things require a bit more work, I am more than willing to give a hand (not ready to take this lying down, I got myself the equipment as a challenge). BMS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 17:56: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 330EE37B42B for ; Fri, 6 Sep 2002 17:55:48 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id B34C243E3B for ; Fri, 6 Sep 2002 17:55:47 -0700 (PDT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 7AC18AE147; Fri, 6 Sep 2002 17:55:47 -0700 (PDT) Date: Fri, 6 Sep 2002 17:55:47 -0700 From: Maxime Henrion To: Kris Kennaway Cc: Peter Wemm , Darren Pilgrim , Matthew Dillon , Dan Nelson , Terry Lambert , Jason Andresen , Dmitry Morozovsky , hackers@FreeBSD.ORG Subject: Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build) Message-ID: <20020907005547.GM86074@elvis.mu.org> References: <3D50664F.71603B49@pantherdragon.org> <20020807015511.A1A092A7D6@canning.wemm.org> <20020906203026.GA78157@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <20020906203026.GA78157@xor.obsecurity.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Kris Kennaway wrote: > On Tue, Aug 06, 2002 at 06:55:11PM -0700, Peter Wemm wrote: > > > `-mcpu=CPU-TYPE' > > Tune to CPU-TYPE everything applicable about the generated code, > > except for the ABI and the set of available instructions. The > > choices for CPU-TYPE are `i386', `i486', `i586', `i686', > > `pentium', `pentium-mmx', `pentiumpro', `pentium2', `pentium3', > > `pentium4', `k6', `k6-2', `k6-3', `athlon', `athlon-tbird', > > `athlon-4', `athlon-xp' and `athlon-mp'. > > > > You can also add -msse, -msse2, -m3dnow to use those extensions. It would > > appear that our bsd.cpu.mk file is out of date and is missing the newer > > cpu types. > > How about the following patch (I've only tested 'pentium3'): [patch ripped] I've got a very similar patch which I believe to be a bit more complete because it also updates the MACHINE_CPU variable which lists the features available on a particular CPU. I attach it to this mail. Cheers, Maxime --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cpu.patch" Index: bsd.cpu.mk =================================================================== RCS file: /space2/ncvs/src/share/mk/bsd.cpu.mk,v retrieving revision 1.16 diff -u -p -r1.16 bsd.cpu.mk --- bsd.cpu.mk 2 Aug 2002 18:04:22 -0000 1.16 +++ bsd.cpu.mk 11 Aug 2002 18:46:06 -0000 @@ -28,8 +28,8 @@ CPUTYPE = ultrasparc CPUTYPE = i686 . elif ${CPUTYPE} == "pentium" CPUTYPE = i586 -. elif ${CPUTYPE} == "athlon" -CPUTYPE = k7 +. elif ${CPUTYPE} == "k7" +CPUTYPE = athlon . endif . endif @@ -42,20 +42,30 @@ CPUTYPE = k7 # http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html . if ${MACHINE_ARCH} == "i386" -. if ${CPUTYPE} == "k7" +. if ${CPUTYPE} == "athlon-mp" +_CPUCFLAGS = -march=athlon-mp +. elif ${CPUTYPE} == "athlon-xp" +_CPUCFLAGS = -march=athlon-xp +. elif ${CPUTYPE} == "athlon-4" +_CPUCFLAGS = -march=athlon-4 +. elif ${CPUTYPE} == "athlon-tbird" +_CPUCFLAGS = -march=athlon-tbird +. elif ${CPUTYPE} == "athlon" _CPUCFLAGS = -march=athlon +. elif ${CPUTYPE} == "k6-3" +_CPUCFLAGS = -march=k6-3 . elif ${CPUTYPE} == "k6-2" -_CPUCFLAGS = -march=k6 +_CPUCFLAGS = -march=k6-2 . elif ${CPUTYPE} == "k6" _CPUCFLAGS = -march=k6 . elif ${CPUTYPE} == "k5" _CPUCFLAGS = -march=pentium . elif ${CPUTYPE} == "p4" -_CPUCFLAGS = -march=pentiumpro +_CPUCFLAGS = -march=pentium4 . elif ${CPUTYPE} == "p3" -_CPUCFLAGS = -march=pentiumpro +_CPUCFLAGS = -march=pentium3 . elif ${CPUTYPE} == "p2" -_CPUCFLAGS = -march=pentiumpro +_CPUCFLAGS = -march=pentium2 . elif ${CPUTYPE} == "i686" _CPUCFLAGS = -march=pentiumpro . elif ${CPUTYPE} == "i586/mmx" @@ -93,8 +103,18 @@ CFLAGS += ${_CPUCFLAGS} # presence of a CPU feature. .if ${MACHINE_ARCH} == "i386" -. if ${CPUTYPE} == "k7" +. if ${CPUTYPE} == "athlon-mp" +MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386 +. elif ${CPUTYPE} == "athlon-xp" +MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386 +. elif ${CPUTYPE} == "athlon-4" +MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386 +. elif ${CPUTYPE} == "athlon-tbird" +MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386 +. elif ${CPUTYPE} == "athlon" MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386 +. elif ${CPUTYPE} == "k6-3" +MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386 . elif ${CPUTYPE} == "k6-2" MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386 . elif ${CPUTYPE} == "k6" --zx4FCpZtqtKETZ7O-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 17:58:40 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C86337B400; Fri, 6 Sep 2002 17:58:37 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-165-226-88.dsl.lsan03.pacbell.net [64.165.226.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82FD143E4A; Fri, 6 Sep 2002 17:58:36 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9998B66C4E; Fri, 6 Sep 2002 17:58:33 -0700 (PDT) Date: Fri, 6 Sep 2002 17:58:33 -0700 From: Kris Kennaway To: Maxime Henrion Cc: Kris Kennaway , Peter Wemm , Darren Pilgrim , Matthew Dillon , Dan Nelson , Terry Lambert , Jason Andresen , Dmitry Morozovsky , hackers@FreeBSD.ORG Subject: Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build) Message-ID: <20020907005833.GA84369@xor.obsecurity.org> References: <3D50664F.71603B49@pantherdragon.org> <20020807015511.A1A092A7D6@canning.wemm.org> <20020906203026.GA78157@xor.obsecurity.org> <20020907005547.GM86074@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <20020907005547.GM86074@elvis.mu.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote: > I've got a very similar patch which I believe to be a bit more complete > because it also updates the MACHINE_CPU variable which lists the > features available on a particular CPU. I attach it to this mail. Oops, I forgot that part. How about sse2 though? Kris --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9eU84Wry0BWjoQKURAg13AJ41Hfrcz4HafWHIngCKzG/fiPHseQCgyTIF x3dqqGw5ojA3Crv9SRS/6/A= =f3L/ -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 18: 8:29 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA86F37B400 for ; Fri, 6 Sep 2002 18:08:24 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46B0143E6A for ; Fri, 6 Sep 2002 18:08:24 -0700 (PDT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id F3ABCAE03F; Fri, 6 Sep 2002 18:08:23 -0700 (PDT) Date: Fri, 6 Sep 2002 18:08:23 -0700 From: Maxime Henrion To: Kris Kennaway Cc: Peter Wemm , Darren Pilgrim , Matthew Dillon , Dan Nelson , Terry Lambert , Jason Andresen , Dmitry Morozovsky , hackers@FreeBSD.ORG Subject: Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build) Message-ID: <20020907010823.GN86074@elvis.mu.org> References: <3D50664F.71603B49@pantherdragon.org> <20020807015511.A1A092A7D6@canning.wemm.org> <20020906203026.GA78157@xor.obsecurity.org> <20020907005547.GM86074@elvis.mu.org> <20020907005833.GA84369@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rQ2U398070+RC21q" Content-Disposition: inline In-Reply-To: <20020907005833.GA84369@xor.obsecurity.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --rQ2U398070+RC21q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Kris Kennaway wrote: > On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote: > > > I've got a very similar patch which I believe to be a bit more complete > > because it also updates the MACHINE_CPU variable which lists the > > features available on a particular CPU. I attach it to this mail. > > Oops, I forgot that part. How about sse2 though? Forgot that one. Here is an updated patch. I'm quite sure that on the Intel side, only the pentium 4 have sse2, but I don't know if any AMD chip supports it yet. The attached patch only adds it for p4's. Cheers, Maxime --rQ2U398070+RC21q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cpu.patch" Index: bsd.cpu.mk =================================================================== RCS file: /home/ncvs/src/share/mk/bsd.cpu.mk,v retrieving revision 1.16 diff -u -p -r1.16 bsd.cpu.mk --- bsd.cpu.mk 2 Aug 2002 18:04:22 -0000 1.16 +++ bsd.cpu.mk 7 Sep 2002 01:05:43 -0000 @@ -28,8 +28,8 @@ CPUTYPE = ultrasparc CPUTYPE = i686 . elif ${CPUTYPE} == "pentium" CPUTYPE = i586 -. elif ${CPUTYPE} == "athlon" -CPUTYPE = k7 +. elif ${CPUTYPE} == "k7" +CPUTYPE = athlon . endif . endif @@ -42,20 +42,30 @@ CPUTYPE = k7 # http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html . if ${MACHINE_ARCH} == "i386" -. if ${CPUTYPE} == "k7" +. if ${CPUTYPE} == "athlon-mp" +_CPUCFLAGS = -march=athlon-mp +. elif ${CPUTYPE} == "athlon-xp" +_CPUCFLAGS = -march=athlon-xp +. elif ${CPUTYPE} == "athlon-4" +_CPUCFLAGS = -march=athlon-4 +. elif ${CPUTYPE} == "athlon-tbird" +_CPUCFLAGS = -march=athlon-tbird +. elif ${CPUTYPE} == "athlon" _CPUCFLAGS = -march=athlon +. elif ${CPUTYPE} == "k6-3" +_CPUCFLAGS = -march=k6-3 . elif ${CPUTYPE} == "k6-2" -_CPUCFLAGS = -march=k6 +_CPUCFLAGS = -march=k6-2 . elif ${CPUTYPE} == "k6" _CPUCFLAGS = -march=k6 . elif ${CPUTYPE} == "k5" _CPUCFLAGS = -march=pentium . elif ${CPUTYPE} == "p4" -_CPUCFLAGS = -march=pentiumpro +_CPUCFLAGS = -march=pentium4 . elif ${CPUTYPE} == "p3" -_CPUCFLAGS = -march=pentiumpro +_CPUCFLAGS = -march=pentium3 . elif ${CPUTYPE} == "p2" -_CPUCFLAGS = -march=pentiumpro +_CPUCFLAGS = -march=pentium2 . elif ${CPUTYPE} == "i686" _CPUCFLAGS = -march=pentiumpro . elif ${CPUTYPE} == "i586/mmx" @@ -93,8 +103,18 @@ CFLAGS += ${_CPUCFLAGS} # presence of a CPU feature. .if ${MACHINE_ARCH} == "i386" -. if ${CPUTYPE} == "k7" +. if ${CPUTYPE} == "athlon-mp" +MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386 +. elif ${CPUTYPE} == "athlon-xp" +MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386 +. elif ${CPUTYPE} == "athlon-4" +MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386 +. elif ${CPUTYPE} == "athlon-tbird" MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386 +. elif ${CPUTYPE} == "athlon" +MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386 +. elif ${CPUTYPE} == "k6-3" +MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386 . elif ${CPUTYPE} == "k6-2" MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386 . elif ${CPUTYPE} == "k6" @@ -102,7 +122,7 @@ MACHINE_CPU = mmx k6 k5 i586 i486 i386 . elif ${CPUTYPE} == "k5" MACHINE_CPU = k5 i586 i486 i386 . elif ${CPUTYPE} == "p4" -MACHINE_CPU = sse i686 mmx i586 i486 i386 +MACHINE_CPU = sse2 sse i686 mmx i586 i486 i386 . elif ${CPUTYPE} == "p3" MACHINE_CPU = sse i686 mmx i586 i486 i386 . elif ${CPUTYPE} == "p2" --rQ2U398070+RC21q-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 18:12:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8834837B400; Fri, 6 Sep 2002 18:12:08 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-165-226-88.dsl.lsan03.pacbell.net [64.165.226.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB42F43E42; Fri, 6 Sep 2002 18:12:07 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2710566C4E; Fri, 6 Sep 2002 18:12:06 -0700 (PDT) Date: Fri, 6 Sep 2002 18:12:05 -0700 From: Kris Kennaway To: Maxime Henrion Cc: Kris Kennaway , Peter Wemm , Darren Pilgrim , Matthew Dillon , Dan Nelson , Terry Lambert , Jason Andresen , Dmitry Morozovsky , hackers@FreeBSD.ORG Subject: Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build) Message-ID: <20020907011205.GA84590@xor.obsecurity.org> References: <3D50664F.71603B49@pantherdragon.org> <20020807015511.A1A092A7D6@canning.wemm.org> <20020906203026.GA78157@xor.obsecurity.org> <20020907005547.GM86074@elvis.mu.org> <20020907005833.GA84369@xor.obsecurity.org> <20020907010823.GN86074@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huq684BweRXVnRxX" Content-Disposition: inline In-Reply-To: <20020907010823.GN86074@elvis.mu.org> User-Agent: Mutt/1.4i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --huq684BweRXVnRxX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 06, 2002 at 06:08:23PM -0700, Maxime Henrion wrote: > Kris Kennaway wrote: > > On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote: > >=20 > > > I've got a very similar patch which I believe to be a bit more comple= te > > > because it also updates the MACHINE_CPU variable which lists the > > > features available on a particular CPU. I attach it to this mail. > >=20 > > Oops, I forgot that part. How about sse2 though? >=20 > Forgot that one. Here is an updated patch. I'm quite sure that on the > Intel side, only the pentium 4 have sse2, but I don't know if any AMD > chip supports it yet. The attached patch only adds it for p4's. Looks good to me! Kris --huq684BweRXVnRxX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9eVJkWry0BWjoQKURAo9UAJoDMx41NGVgPsFqXkID11JVJG3fhQCgtf3l e3uy9OykjGHGZuhkDirbNns= =nB0K -----END PGP SIGNATURE----- --huq684BweRXVnRxX-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 18:42:12 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9655437B401; Fri, 6 Sep 2002 18:42:07 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04CED43E6E; Fri, 6 Sep 2002 18:42:03 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 453882A7D6; Fri, 6 Sep 2002 18:41:59 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Maxime Henrion Cc: Kris Kennaway , Darren Pilgrim , Matthew Dillon , Dan Nelson , Terry Lambert , Jason Andresen , Dmitry Morozovsky , hackers@FreeBSD.ORG Subject: Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build) In-Reply-To: <20020907010823.GN86074@elvis.mu.org> Date: Fri, 06 Sep 2002 18:41:59 -0700 From: Peter Wemm Message-Id: <20020907014159.453882A7D6@canning.wemm.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxime Henrion wrote: > Kris Kennaway wrote: > > On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote: > > > > > I've got a very similar patch which I believe to be a bit more complete > > > because it also updates the MACHINE_CPU variable which lists the > > > features available on a particular CPU. I attach it to this mail. > > > > Oops, I forgot that part. How about sse2 though? > > Forgot that one. Here is an updated patch. I'm quite sure that on the > Intel side, only the pentium 4 have sse2, but I don't know if any AMD > chip supports it yet. The attached patch only adds it for p4's. Both of the Hammer cpus support SSE2 FWIW. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 21:18:20 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6240A37B400; Fri, 6 Sep 2002 21:18:18 -0700 (PDT) Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id D006A43E72; Fri, 6 Sep 2002 21:18:17 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g874Hwv37969; Fri, 6 Sep 2002 21:17:58 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Fri, 6 Sep 2002 21:17:58 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Lars Eggert Cc: "Kenneth D. Merry" , Peter Wemm , jlemon@flugsvamp.com, hackers@FreeBSD.ORG, mjacob@FreeBSD.ORG Subject: Re: Ultra320 drivers? In-Reply-To: <3D6FEC88.6070106@isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Things are looking a bit better- I have your system at a comfortable clip with multiple tasks. I'll leave some tests over the weekend, but I think I nailed it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 22:54: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0667137B401 for ; Fri, 6 Sep 2002 22:53:50 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55A4043E65 for ; Fri, 6 Sep 2002 22:53:48 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g875pGGq018569; Fri, 6 Sep 2002 23:53:46 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 06 Sep 2002 23:51:10 -0600 (MDT) Message-Id: <20020906.235110.108188889.imp@bsdimp.com> To: bms@spc.org Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: PCMCIA questions: mapping attribute and common memory? From: "M. Warner Losh" In-Reply-To: <20020906093215.GI15218@spc.org> References: <20020905191546.GF15218@spc.org> <20020905.145936.39157187.imp@bsdimp.com> <20020906093215.GI15218@spc.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020906093215.GI15218@spc.org> Bruce M Simpson writes: : Thanks for your informative response. Sure. Sorry for the long delay on this one. I wanted to give a good answer rather than a fast one. : On Thu, Sep 05, 2002 at 02:59:36PM -0600, M. Warner Losh wrote: : > You generally don't map attribute memory. With one exception (the : > raylan cards), there's no hardware in the attribute memory section and : > it is just used to store the cis. : ... : [ray(4) and xe(4)] : > Those are the two worst ones to look at. Don't do what they do, as : > the ray(4) hardware is weird and the xe(4) driver was written before : > we could read the cis from the kernel. : : The particular device I'm working with is the Gemplus GPR400 PCMCIA : Smart Card Reader. It has hardware registers in the attribute memory. Yuck! Fortunately, I've been sensitized to it by the raylink driver. : One of these registers tells me when a card is inserted/ejected, and : there are also some bits in that space which are used to handle : suspending and resuming the card. ok. : What's the best way for me to do this, whilst being OLDCARD and NEWCARD : compatible? (And just out of interest, is it possible to read the CIS : from the kernel easily whilst still being OLDCARD friendly?) Do you need to read the CIS directly? Or do you just need to map the attribute memory to access well known locationss? The answer isn't much different, and I'll get into that below. : > : If so, how do I get at the resource? : > : If not, how would I go about doing this myself in the driver? : > : > bus_alloc_resource() : : Ok. Say I have my first two tuples and they look like this:- : : Tuple #1, code = 0x1 (Common memory descriptor), length = 3 : 000: d4 00 ff : Common memory device information: : Device number 1, type Function specific, WPS = OFF : Speed = 100nS, Memory block size = 512b, 1 units : : Tuple #2, code = 0x17 (Attribute memory descriptor), length = 3 : 000: 64 10 ff : Attribute memory device information: : Device number 1, type SRAM, WPS = OFF : Speed = 100nS, Memory block size = 512b, 3 units : : How will these blocks be mapped when I allocate the resource? They are memory mapped devices. : Are they : coalesced into a single memory map in the order in which they appear in the : CIS? Thing is, 2KB is 0x800 hex, and the register addresses I see in this : Linux code I'm porting all start at 0xFA0. This would seem to indicate : that a 2KB memory window is needed. [(3+1)*512]. The Linux code asks for a : window size of 0x1000, which is 4KB, yet the comment says it's asking for : 2KB. Bizarre. Linux code tends to say one thing and do another often. :-) : Once I've allocated the window as a resource, how would I go about accessing : that memory directly? Would I need to establish a page mapping? OK. Lemme talk with code (which I've grabbed from ray_res_alloc_am) sc->am_rid = RAY_AM_RID; sc->am_res = bus_alloc_resource(sc->dev, SYS_RES_MEMORY, &sc->am_rid, 0UL, ~0UL, 0x1000, RF_ACTIVE); error = CARD_SET_MEMORY_OFFSET(device_get_parent(sc->dev), sc->dev, sc->am_rid, 0, NULL); error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, SYS_RES_MEMORY, sc->am_rid, PCCARD_A_MEM_ATTR); error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, SYS_RES_MEMORY, sc->am_rid, PCCARD_A_MEM_8BIT); (I'm not sure why the ray driver doesn't combine the last two calls). The rid is 3. pccardd abuses window 0 (and the comments in the ray driver say 1 also, which may be possible). We really should use window 4 for the CIS, but that's too big a change (and would break support for media chipsets, which have only one memory map, but those are only on early pc98 laptops). Anyway, you pick the window that you want to use. You the map it. To manage where in the memory you'd like to map it, you set the offset. To make it the attribute memory, we set the resoruce flags. Ditto with 8 bit. Allocating the common memory would be similar. In the ray driver, it uses rid 0 for the common memory so it can get the size of the memory. So that code looks like: u_long start, count, end; sc->cm_rid = RAY_CM_RID; start = bus_get_resource_start(sc->dev, SYS_RES_MEMORY, sc->cm_rid); count = bus_get_resource_count(sc->dev, SYS_RES_MEMORY, sc->cm_rid); end = start + count - 1; sc->cm_res = bus_alloc_resource(sc->dev, SYS_RES_MEMORY, &sc->cm_rid, start, end, count, RF_ACTIVE); error = CARD_SET_MEMORY_OFFSET(device_get_parent(sc->dev), sc->dev, sc->cm_rid, 0, NULL); error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, SYS_RES_MEMORY, sc->cm_rid, PCCARD_A_MEM_COM); error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, SYS_RES_MEMORY, sc->cm_rid, PCCARD_A_MEM_8BIT); which is very similar. This only works because the rid is 0. I'm not sure what the CIS of the ray cards look like (my ray cards aren't easily accessible at the moment). So if you need to read the CIS, you'll have to find out where in the attribute memory the CIS lives. There are ways to do this generically for pccards, but I don't know if you can do it inside a client driver. The -current version uses some of the generic information passed in from pccardd. I need to MFC that functionality into -stable. : [probe] : > Ideally, you'd just match the OEM ID and vendor info of the card. : > Less ideally, you'd match the strings in the CIS. : : So why do many pccard driver probes allocate and deallocate their : card's resources? Is this merely to make sure they're available in : anticipation of attach? That's a legacy of OLDCARD and ISA. Old-school ISA devices needed to be querried to make sure they were still there. Many of these probe routines bogusly had side effects, either in the hardware or in the softc of the driver. So rather than fix them all when we were adding pccard attachments to these devices, we just made pccard devices do the same thing as ISA. NEWCARD encourages folks to just use the IDs to figure this out. So how do you make things compatible between NEWCARD and OLDCARD? Well, they are basically the same. However, the is a slight difference. In OLDCARD, pccardd desided what driver will be used, probe looks for hardware, and attach connects it. NEWCARD one is just supposed to look at the ids, while attach is supposed to ready the hardware and allocate things. How can these two models be reconsiled? With some compat shims. Let's take a look at how ep does it: static device_method_t ep_pccard_methods[] = { /* Device interface */ DEVMETHOD(device_probe, pccard_compat_probe), DEVMETHOD(device_attach, pccard_compat_attach), DEVMETHOD(device_detach, ep_pccard_detach), /* Card interface */ DEVMETHOD(card_compat_match, ep_pccard_match), DEVMETHOD(card_compat_probe, ep_pccard_probe), DEVMETHOD(card_compat_attach, ep_pccard_attach), { 0, 0 } }; Notice two things. First, probe and attach are a generic shim that calls either the OLDCARD or the NEWCARD routines. We also provide 3 generic routines. 1 that matches, one that probes and one that attaches. The reason I split them up was that OLDCARD's agent of driver choice is pccardd, while in NEWCARD it is the driver itself. So, ep_pccard_match looks fairly simple: static int ep_pccard_match(device_t dev) { const struct pccard_product *pp; if ((pp = pccard_product_lookup(dev, ep_pccard_products, sizeof(ep_pccard_products[0]), NULL)) != NULL) { device_set_desc(dev, pp->pp_name); return 0; } return EIO; } and most drivers will have some variation on this. Some drivers have additional information in their tables and they look things up to find info specific to that device (which is why we pass the size into the lookup routine). The ep_pccard_probe routine then looks for the hardware. It did this to provide a reasonable string in the description. Your driver likely won't want to do this. The ep_pccard_attach routine allocates resources. Your driver will want to allocate resources here and set things up. For OLDCARD, pccard_compat_probe calls ep_pccard_probe, and pccard_compat_attach calls ep_pccard_attach. For NEWCARD, pccard_compat_probe calls ep_pccard_match and pccard_compat_probe calls ep_pccard_probe and ep_pccard_attach. Well, that's enough for now. Any further questions? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 23:41: 1 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D1AF37B400; Fri, 6 Sep 2002 23:40:55 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D6D343E75; Fri, 6 Sep 2002 23:40:54 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g876eTAg035481; Sat, 7 Sep 2002 08:40:42 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Nate Lawson Cc: Bruce M Simpson , hackers@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: New scsi_target code In-Reply-To: Your message of "Fri, 06 Sep 2002 17:32:29 PDT." Date: Sat, 07 Sep 2002 08:40:29 +0200 Message-ID: <35480.1031380829@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Nate Lawson writ es: >On Thu, 5 Sep 2002, Bruce M Simpson wrote: >> On Thu, Sep 05, 2002 at 01:54:08AM -0700, Nate Lawson wrote: >> > I have rewritten the scsi_target driver and usermode client with a much >> > simpler model suggested by Justin Gibbs. The kernel driver receives >> >> This sounds like excellent work and I can't wait to check it out further. >> Whilst looking into the problem of USB->ATA bridge support I was recently >> faced with the problem of writing various ATA->SCSI command translations, >> which involved emulating a SCSI device, so I imagine your code should be >> very useful. > >Possibly. I have updated the version online with a patch for >-current. It builds and runs but panics in read/write. I'll look into >the issues with -current over the weekend. > >I'm very interested in comments and testing on -stable to help update the >general architecture and stability. IP-over-SCSI ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Sep 6 23:49: 4 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60E5537B400 for ; Fri, 6 Sep 2002 23:48:58 -0700 (PDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D9BF43E4A for ; Fri, 6 Sep 2002 23:48:58 -0700 (PDT) (envelope-from seva3@pacbell.net) Received: from enisey ([66.123.222.250]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0H2200A0V2XLOS@mta5.snfc21.pbi.net> for hackers@freebsd.org; Fri, 06 Sep 2002 23:48:57 -0700 (PDT) Date: Fri, 06 Sep 2002 23:48:11 -0700 From: Seva Tonkonoh Subject: RE: intermezzo? In-reply-to: <3D789A9E.A8E3B54@mindspring.com> To: Terry Lambert Cc: hackers@freebsd.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG It's very encouraging to see replies like that. Thanks a lot! /seva -----Original Message----- From: owner-freebsd-hackers@FreeBSD.ORG [mailto:owner-freebsd-hackers@FreeBSD.ORG]On Behalf Of Terry Lambert Sent: Friday, September 06, 2002 5:08 AM To: Seva Tonkonoh Cc: freebsd-hackers@freebsd.org Subject: Re: intermezzo? Seva Tonkonoh wrote: > I have recently come across an old little discussion about InterMezzo. > I 've got the impression that it wasn't really welcome to FreeBSD. It's illegal to distribute a binary FreeBSD distribution with GPL'ed components linked into the kernel because of clause 6 of the GPL. As long as the boot FS is not InterMezzo, and the FS is loaded as a seperately compiled module, there should be no problem with it. I kind of wish they'd LGPL'ed it, or figured some other way to not "poison pill" the code, but it still seems like it could be used. > Just curious if something similar has been done for FreeBSD, or if > someone is working on such thing. Sarnoff has done a similar implementation for FreeBSD, called MNFS, which had an integrated distributed cache coherency protocol, and was implemented for FreeBSD circa 1996. The InterMezzo paper suggest that we call te driver that implements this "a cache filter driver"; standard terminaology says we should call them "oplocks" ("opportunistic locks") or "leases". NFSv3 and NFSv4 have these features, in increasing order of integration. They note this in section 3 of their paper, but maintain their use of the "callback"/"filter driver" terminology. Maybe they wanted a patent. 8-). InterMezzo also appears to want to disable the local buffer cache, with regard to involvement in open/close (section 4). Since the VM and buffer cache are integrated in FreeBSD, this is not really possible to do. The concentration on "open/close" time is probably at fault here; you could get the same effect by caching file handles, where a real close lags some time after a close request, so that the open can be reacquired without a probem. IMO, though, this is very much an artifact of the use of Coda, and not a general optimization applicable to a correctly written distributed FS client. Some of the benchmarks are pretty bogus in the writeback caching (section 5). In particular, the mkdir/rmdir "benchmark" is a bit contrived, compared to real world usage patterns for FS's. > I am actually looking for an MS research project topic and > Intermezzo seemed to be an interesting possibility. > Other suggestions would be also helpful. You could implement this as a stacking VFS module fairly easily, beginning with the NULLFS code. The cache coherency issues in FreeBSD mean that you will be converting get/put page operations into read/write operations in your FS stacking layer (FreeBSD does not properly support stacking of all VOP's, at present), but the performance impact for the microbenchmarks in question should not really affect your FreeBSD numbers (the microbenchmarks that are describd in the paper bear little resemblance to "real work", so things that will hurt the performance of "real work", won't hurt the results of the microbenchmarks; guess you could say that was a good thing ;^)). The paper also doesn't really apply to FreeBSD; the FFS sync issues that it describes are vs. the NetBSD Coda implementation. The FFS in FreeBSD overcomes most of these issues via Soft Updates. They also could have mounted the FS async in NetBSD, to put it on a par with the speed and reliability of Ext2. All in all, it looks like an interesting thing to play with, and since you aren't going to boot from it, it's not prohibitive in the ability of people to really use the work, like an XFS or JFS GPL'ed FS that you would use as your root/boot FS would be. If you need a proof of concept, then you should block diagram out an implementation, assuming VFS stacking, and see if it can work that way (IMO, it can, bt I don't know how accurately the diagrams in the InterMezzo paper represent the interface encapsulation they imply). The most important consideration in any MS project is whether or not the project is interesting to you, and what you can get out of it (IMO). Whatever you do, do it for yourself, and if it's useful to anyone else, that's just gravy. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 0: 0:35 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D04A37B40A; Sat, 7 Sep 2002 00:00:27 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A8A843E6A; Sat, 7 Sep 2002 00:00:26 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020907070025.BGCA25823.sccrmhc02.attbi.com@InterJet.elischer.org>; Sat, 7 Sep 2002 07:00:25 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id XAA45366; Fri, 6 Sep 2002 23:47:09 -0700 (PDT) Date: Fri, 6 Sep 2002 23:47:08 -0700 (PDT) From: Julian Elischer To: Poul-Henning Kamp Cc: Nate Lawson , Bruce M Simpson , hackers@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: New scsi_target code In-Reply-To: <35480.1031380829@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 7 Sep 2002, Poul-Henning Kamp wrote: > > IP-over-SCSI ? > Well I've just been reading about SCSI over IP.... so Scsi-over-IP-over-SCSI-over-firewire? etc... :-/ 8-S To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 0: 5:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94D8737B400; Sat, 7 Sep 2002 00:05:41 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B043343E3B; Sat, 7 Sep 2002 00:05:40 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.3/8.12.2) with ESMTP id g8775MAg035903; Sat, 7 Sep 2002 09:05:23 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Julian Elischer Cc: Nate Lawson , Bruce M Simpson , hackers@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: New scsi_target code In-Reply-To: Your message of "Fri, 06 Sep 2002 23:47:08 PDT." Date: Sat, 07 Sep 2002 09:05:22 +0200 Message-ID: <35902.1031382322@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Ju lian Elischer writes: > > >On Sat, 7 Sep 2002, Poul-Henning Kamp wrote: >> >> IP-over-SCSI ? >> > >Well I've just been reading about SCSI over IP.... so That's different. IP-over-SCSI is a much wanted Myrinet-light over here. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 0:49:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBE9137B400 for ; Sat, 7 Sep 2002 00:49:25 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id E53F343E6A for ; Sat, 7 Sep 2002 00:49:24 -0700 (PDT) (envelope-from phoenix@minion.de) Received: from [212.227.126.162] (helo=mrelayng3.kundenserver.de) by moutng4.kundenserver.de with esmtp (Exim 3.35 #2) id 17naKk-0000bs-00; Sat, 07 Sep 2002 09:48:46 +0200 Received: from [80.144.20.168] (helo=chronos) by mrelayng3.kundenserver.de with asmtp (Exim 3.35 #1) id 17naKk-0006v8-00; Sat, 07 Sep 2002 09:48:46 +0200 Received: from phoenix by chronos with local (Exim 3.35 #1 (Debian)) id 17naJT-0000jb-00; Sat, 07 Sep 2002 09:47:27 +0200 Date: Sat, 7 Sep 2002 09:47:26 +0200 From: Christian Zander To: Nate Lawson Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: interrupting the remote kernel Message-ID: <20020907094726.K652@chronos> Reply-To: Christian Zander References: <20020906220033.A1830@gicco.cablecom.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-Operating-System: GNU/Linux [2.4.19][i686] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 06, 2002 at 05:17:07PM -0700, Nate Lawson wrote: > > > But I want to be able to pass control to the debugger when > > the target kernel `hangs', that is when no `ctl-alt-f1', > > `ctl-alt-del' has any effect. > > If the hang is not a system hang, the console break will have > an effect. But if the kernel is so hung that the keyboard > doesn't work, the remote serial console will not do you any > better. In this case you need a box with a real console (i.e. > Sun). > What I found to work well is remote GDB debugging with the UDP wrapper (ip-gdb), it responds to CTRL-C as expected. -- christian zander zander@minion.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 1: 0:39 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60FA437B413 for ; Sat, 7 Sep 2002 01:00:32 -0700 (PDT) Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A24543E3B for ; Sat, 7 Sep 2002 01:00:31 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org ([12.232.206.8]) by sccrmhc02.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020907080012.COXD25823.sccrmhc02.attbi.com@InterJet.elischer.org>; Sat, 7 Sep 2002 08:00:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id AAA45655; Sat, 7 Sep 2002 00:56:12 -0700 (PDT) Date: Sat, 7 Sep 2002 00:56:12 -0700 (PDT) From: Julian Elischer To: Christian Zander Cc: Nate Lawson , freebsd-hackers@FreeBSD.ORG Subject: Re: interrupting the remote kernel In-Reply-To: <20020907094726.K652@chronos> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 7 Sep 2002, Christian Zander wrote: > On Fri, Sep 06, 2002 at 05:17:07PM -0700, Nate Lawson wrote: > > > > > But I want to be able to pass control to the debugger when > > > the target kernel `hangs', that is when no `ctl-alt-f1', > > > `ctl-alt-del' has any effect. > > > > If the hang is not a system hang, the console break will have > > an effect. But if the kernel is so hung that the keyboard > > doesn't work, the remote serial console will not do you any > > better. In this case you need a box with a real console (i.e. > > Sun). > > > > What I found to work well is remote GDB debugging with the UDP > wrapper (ip-gdb), it responds to CTRL-C as expected. huh? do we have that? (rushes of to see it it's in ports) comes back sadly.. (where do you get it from?) > > -- > christian zander > zander@minion.de > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 1:31:54 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C32D37B400 for ; Sat, 7 Sep 2002 01:31:12 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DF4143E3B for ; Sat, 7 Sep 2002 01:31:11 -0700 (PDT) (envelope-from phoenix@minion.de) Received: from [212.227.126.161] (helo=mrelayng2.kundenserver.de) by moutng3.kundenserver.de with esmtp (Exim 3.35 #2) id 17nayT-0002Uc-00; Sat, 07 Sep 2002 10:29:49 +0200 Received: from [80.144.20.168] (helo=chronos) by mrelayng2.kundenserver.de with asmtp (Exim 3.35 #1) id 17nayR-0002sz-00; Sat, 07 Sep 2002 10:29:47 +0200 Received: from phoenix by chronos with local (Exim 3.35 #1 (Debian)) id 17nax9-0000lg-00; Sat, 07 Sep 2002 10:28:27 +0200 Date: Sat, 7 Sep 2002 10:28:27 +0200 From: Christian Zander To: Julian Elischer Cc: Christian Zander , Nate Lawson , freebsd-hackers@FreeBSD.ORG Subject: Re: interrupting the remote kernel Message-ID: <20020907102827.L652@chronos> Reply-To: Christian Zander References: <20020907094726.K652@chronos> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.22.1i X-Operating-System: GNU/Linux [2.4.19][i686] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Sep 07, 2002 at 12:56:12AM -0700, Julian Elischer wrote: > > > What I found to work well is remote GDB debugging with the UDP > > wrapper (ip-gdb), it responds to CTRL-C as expected. > > huh? do we have that? > (rushes of to see it it's in ports) > comes back sadly.. > > (where do you get it from?) > Yes, Tim Gilman posted about this on freebsd-hackers earlier this year, the project has been sittling idle since, but can still be found here: http://sourceforge.net/projects/ipgdb/. I did a little bit of work on it to make it work in environments with routers; I sent a patch to Tim, but have not yet heard back. I attached this updated version as a patch that should apply cleanly against 4.5+. It will work with eepro100 adapters in my version, but adding the necessary support for other NICs is trivial. The complete patch also needs to change a few lines in gdb to make it work, this is included in the original patch, but not in the one I attached. -- christian zander zander@minion.de --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ipgdb.diff" Binary files 4.5/compile/DEBUG/kernel.debug and sys/compile/DEBUG/kernel.debug differ diff -ruN 4.5/conf/files sys/conf/files --- 4.5/conf/files Tue Mar 26 02:12:22 2002 +++ sys/conf/files Sat Jun 22 17:14:38 2002 @@ -523,6 +523,10 @@ i4b/layer4/i4b_l4mgmt.c optional i4b i4b/layer4/i4b_l4timer.c optional i4b # +# UDP wrapper for serial GDB stub +# +ipgdb/ipgdb.c optional ip_gdb +# isofs/cd9660/cd9660_bmap.c optional cd9660 isofs/cd9660/cd9660_lookup.c optional cd9660 isofs/cd9660/cd9660_node.c optional cd9660 diff -ruN 4.5/conf/options sys/conf/options --- 4.5/conf/options Tue Feb 19 15:08:49 2002 +++ sys/conf/options Sat Jun 22 17:01:49 2002 @@ -63,6 +63,10 @@ DDB DDB_UNATTENDED opt_ddb.h GDB_REMOTE_CHAT opt_ddb.h + +IP_GDB opt_ip_gdb.h +IP_GDB_FXP opt_ip_gdb_fxp.h + HW_WDOG KTRACE LIBICONV diff -ruN 4.5/dev/fxp/if_fxp.c sys/dev/fxp/if_fxp.c --- 4.5/dev/fxp/if_fxp.c Mon Feb 11 15:22:43 2002 +++ sys/dev/fxp/if_fxp.c Sat Jun 22 17:08:56 2002 @@ -77,6 +77,8 @@ #include #include +#include "opt_ip_gdb_fxp.h" + MODULE_DEPEND(fxp, miibus, 1, 1, 1); #include "miibus_if.h" @@ -169,7 +171,12 @@ static int fxp_suspend(device_t dev); static int fxp_resume(device_t dev); -static void fxp_intr(void *xsc); +#ifdef IP_GDB_FXP +void fxp_intr(void *xsc); +#else +static void fxp_intr(void *xsc); +#endif + static void fxp_intr_body(struct fxp_softc *sc, u_int8_t statack, int count); @@ -1179,7 +1186,11 @@ /* * Process interface interrupts. */ +#ifdef IP_GDB_FXP +void +#else static void +#endif fxp_intr(void *xsc) { struct fxp_softc *sc = xsc; diff -ruN 4.5/i386/i386/i386-gdbstub.c sys/i386/i386/i386-gdbstub.c --- 4.5/i386/i386/i386-gdbstub.c Wed Aug 2 17:54:41 2000 +++ sys/i386/i386/i386-gdbstub.c Thu Jun 20 16:01:29 2002 @@ -102,8 +102,11 @@ #include +#include + #include "sio.h" #include "opt_ddb.h" +#include "opt_ip_gdb.h" void gdb_handle_exception (db_regs_t *, int, int); @@ -489,13 +492,22 @@ *ptr++ = 0; +#ifdef IP_GDB + ipgdb_putpacket_add_wrapper (remcomOutBuffer); +#else putpacket (remcomOutBuffer); +#endif while (1) { remcomOutBuffer[0] = 0; +#ifdef IP_GDB + ipgdb_getpacket (remcomInBuffer); +#else getpacket (remcomInBuffer); +#endif + switch (remcomInBuffer[0]) { case '?': @@ -506,7 +518,12 @@ break; case 'D': /* detach; say OK and turn off gdb */ +#ifdef IP_GDB + ipgdb_putpacket_add_wrapper(remcomOutBuffer); + ipgdb_connected = 0; +#else putpacket(remcomOutBuffer); +#endif boothowto &= ~RB_GDB; return; @@ -608,11 +625,17 @@ raw_regs->tf_ds = registers.ds; raw_regs->tf_es = registers.es; return; - + /* default: */ + /* if we don't recognize a packet, reply with empty packet */ } /* switch */ /* reply to the request */ +#ifdef IP_GDB + ipgdb_putpacket_add_wrapper (remcomOutBuffer); +#else putpacket (remcomOutBuffer); +#endif } } #endif /* NSIO > 0 */ + diff -ruN 4.5/ipgdb/ipgdb.c sys/ipgdb/ipgdb.c --- 4.5/ipgdb/ipgdb.c Wed Dec 31 16:00:00 1969 +++ sys/ipgdb/ipgdb.c Sat Jun 22 17:40:59 2002 @@ -0,0 +1,712 @@ +/* + * Copyright (c) 2002 + * Panasas, Inc. All rights reserved. + * + * Some of this code is derived from FreeBSD sources. See Copyright + * below. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by Panasas, Inc. + * 4. The name of Panasas, Inc. may not be used to endorse or promote + * products derived from this software without specific prior written + * permission. + * + * THIS SOFTWARE IS PROVIDED BY PANASAS, INC. ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL PANASAS, INC. BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ +/* + * Copyright (c) 1980, 1986, 1991, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ +/* ipgdb.c + * + * UDP implementation for remote debugger. + * Ideas lifted from NetBSD's ipkdb. + * + */ + +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include +#include +#define _IP_VHL +#include +#undef _IP_VHL +#include +#include +#include + +#include + +#include + +#include +#include + +#include /* for DELAY */ + +#include + +/* To get the GDB related variables */ +#include + +#include "opt_ip_gdb_fxp.h" + +#define BUFMAX 400 + +static char ipgdb_inbuf[BUFMAX]; +static char ipgdb_outbuf[BUFMAX]; +static char *ipgdb_getoff; +static int ipgdb_gotone = 0; /* only if we have cmd packet */ +int ipgdb_connected = 0; +static int ipgdb_ack_packet = 0; /* only if recv'd + packet */ +static struct ifnet *ipgdb_ifp; +static struct sockaddr_in ipgdb_ip_us; +static struct sockaddr_in ipgdb_ip_them; +static u_char ipgdb_ether_us[ETHER_ADDR_LEN]; +static u_char ipgdb_ether_them[ETHER_ADDR_LEN]; + +/* need prototype to clobber warning */ +/* NIC_intr is the NIC's interrupt handler. AFAIK there's no way + * to call this function except directly. + * + * To enable a different NIC, go make NIC_intr not static, and + * add code as below: + */ + +#ifdef IP_GDB_FXP +extern void fxp_intr __P((void *)); +#endif +#ifdef IP_GDB_SIS +extern void sis_intr __P((void *)); +#endif + +/* + * We need to make sure that the target machine still responds to ARP + * requests when trapped in the debugger. If it doesn't, routers will + * assume that it is no longer available and send ICMP "Destination + * Unreachable", "Host Unreachable" error messages to remotes sending + * packets to the target. Similarly to NIC_intr(), arpintr() needs to + * be called regularly to prevent this from happening. + */ + +extern void arpintr __P((void)); + +#ifndef IP_GDB_FXP +#ifndef IP_GDB_SIS +#error You must specify an interface with IPGDB. Eg, in your config file, add "IP_GDB_nic". +#endif +#endif + + +static int +ipgdb_strlen (const char *s) +{ + const char *s1 = s; + + while (*s1++ != '\000'); + + return s1 - s; +} + + +char * +ipgdb_strcpy (char *dst, const char *src) +{ + char *retval = dst; + + while ((*dst++ = *src++) != '\000'); + + return retval; +} + + +static void +ipgdb_copy(void *s, void *d, int n) +{ + char *sp = s, *dp = d; + + while (--n >= 0) + *dp++ = *sp++; +} + + +void +ipgdb_fillbuff (const char *src) +{ + (void)ipgdb_strcpy(ipgdb_inbuf, src); + ipgdb_getoff = ipgdb_inbuf; +} + + +static u_int ipgdb_getns __P((void *)); + +__inline static u_int +ipgdb_getns(void *vs) +{ + u_char *s = vs; + + return (*s << 8)|s[1]; +} + + +static const char hexchars[]="0123456789abcdef"; + +static int +hex(char ch) +{ + if ((ch >= 'a') && (ch <= 'f')) + return (ch-'a'+10); + if ((ch >= '0') && (ch <= '9')) + return (ch-'0'); + if ((ch >= 'A') && (ch <= 'F')) + return (ch-'A'+10); + return (-1); +} + + +/* gdb-stub uses put/getpacket to talk to remote */ +void +ipgdb_putpacket_add_wrapper(char *buffer) +{ + /* we're passed a buffer filled with Important Data, */ + /* wrap it up and send it out.. */ + unsigned char checksum; + int count; + unsigned char ch, *c_ptr; + + /* sending an empty buffer is the appropriate response + * to unknown/unsupported gdb commands + */ + while (ipgdb_connected == 0) { + DELAY(1000000); + } + + c_ptr = ipgdb_outbuf; + *c_ptr++ = '$'; /* special header character */ + checksum = 0; + count = 0; + + while ((ch = buffer[count]) != 0) + { + checksum += ch; + count += 1; + *c_ptr++ = ch; /* add the guts of message */ + } + + *c_ptr++ = '#'; /* special marker */ + /* after special marker, insert checksum */ + *c_ptr++ = hexchars[checksum >> 4]; + *c_ptr++ = hexchars[checksum & 0xf]; + + *c_ptr = '\000'; + + ipgdb_putpacket(ipgdb_outbuf); +} + + +static u_short ipgdb_ip_id; + +void +ipgdb_putpacket(char *snd_buf) +{ + register struct udpiphdr *ui; + register struct ether_header *eh; + struct ip *ip_ptr; + struct mbuf *m; + int s, length, sw_csum; + int hlen = sizeof(struct ip); + short type; + + /* now send packet. need to build packet first */ + /* put data into mbuf form */ + m = m_devget(snd_buf, ipgdb_strlen(snd_buf), 0, ipgdb_ifp, NULL); + + length = m->m_pkthdr.len; + + /* jmb, the length is actually really restricted. + * it should be set to the path mtu to avoid ip fragmentation + * assume mtu is that of ethernet, 1472 ( 1500-sizeof(ip+udp headers)) + */ + if (length > 1472) { + printf("ipgdb_putpacket: EMSGSIZE: %s\n", snd_buf); + m_freem(m); + return; + } + + /* slap on udp & ip headers */ + M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT); + if (m == 0) { + printf("ipgdb_putpacket: ENOBUFS: %s\n", snd_buf); + m_free(m); + return; + } + + /* fill in headers */ + ui = mtod(m, struct udpiphdr *); + bzero(ui->ui_x1, sizeof(ui->ui_x1)); /* XXX still needed? */ + ui->ui_pr = IPPROTO_UDP; + ui->ui_src = ipgdb_ip_us.sin_addr; + ui->ui_dst = ipgdb_ip_them.sin_addr; + ui->ui_sport = ipgdb_ip_us.sin_port; + ui->ui_dport = ipgdb_ip_them.sin_port; + ui->ui_ulen = htons((u_short)length + sizeof(struct udphdr)); + + /* tack on udp checksum */ + ui->ui_sum = in_pseudo(ui->ui_src.s_addr, ui->ui_dst.s_addr, + htons((u_short)length + sizeof(struct udphdr) + IPPROTO_UDP)); + m->m_pkthdr.csum_flags = CSUM_UDP; + m->m_pkthdr.csum_data = offsetof(struct udphdr, uh_sum); + /* end of UDP section */ + + ((struct ip *)ui)->ip_len = sizeof (struct udpiphdr) + length; + ((struct ip *)ui)->ip_ttl = 127; /* XXX */ + + /* begin IP section (ip_output:.c) */ + ip_ptr = mtod(m, struct ip *); + + ip_ptr->ip_vhl = IP_MAKE_VHL(IPVERSION, hlen >> 2); + ip_ptr->ip_off &= IP_DF; + ip_ptr->ip_id = htons(ipgdb_ip_id++); + + /* IP checksum */ + sw_csum = m->m_pkthdr.csum_flags | CSUM_IP; + m->m_pkthdr.csum_flags = sw_csum & ipgdb_ifp->if_hwassist; + sw_csum &= ~ipgdb_ifp->if_hwassist; + if (sw_csum & CSUM_DELAY_DATA) { + in_delayed_cksum(m); + sw_csum &= ~CSUM_DELAY_DATA; + } + + HTONS(ip_ptr->ip_len); + HTONS(ip_ptr->ip_off); + ip_ptr->ip_sum = 0; + + if (sw_csum & CSUM_DELAY_IP) { + if (ip_ptr->ip_vhl == IP_VHL_BORING) { + ip_ptr->ip_sum = in_cksum_hdr(ip_ptr); + } else { + ip_ptr->ip_sum = in_cksum(m, hlen); + } + } + + /* ready to send */ + + /* go straight to ethernet, do not pass IP */ + type = htons(ETHERTYPE_IP); + + M_PREPEND(m, sizeof(struct ether_header), M_DONTWAIT); + if (m == 0) { + printf("ipgdb: error building ether header\n"); + m_freem(m); + return; + } + eh = mtod(m, struct ether_header *); + (void)memcpy(&eh->ether_type, &type, sizeof(eh->ether_type)); + (void)memcpy(eh->ether_dhost, ipgdb_ether_them, sizeof(ipgdb_ether_them)); + (void)memcpy(eh->ether_shost, ipgdb_ether_us, sizeof(ipgdb_ether_us)); + + /* time to stuff this into the driver */ + + s = splimp(); + if (IF_QFULL(&ipgdb_ifp->if_snd)) { + IF_DROP(&ipgdb_ifp->if_snd); + splx(s); + m_freem(m); + printf("ipgdb: IF_QFULL, looks full\n"); + return; + } + IF_ENQUEUE(&ipgdb_ifp->if_snd, m); + /* if ((ipgdb_ifp->if_flags & IFF_OACTIVE) == 0) */ + (*ipgdb_ifp->if_start)(ipgdb_ifp); + splx(s); + + /* this grossness is due to the fact that on connection, + * gdb-host sends two packets, a + and then something. + */ + if (ipgdb_ack_packet == 1) { + ipgdb_ack_packet = 0; + return; + } + + /* wait for an ack packet */ + if (*snd_buf != '+' && *snd_buf != '-') { + while (ipgdb_ack_packet == 0) { + DELAY(10000); +#ifdef IP_GDB_FXP + fxp_intr(ipgdb_ifp->if_softc); +#endif +#ifdef IP_GDB_SIS + sis_intr(ipgdb_ifp->if_softc); +#endif + } + ipgdb_ack_packet = 0; + } +} + + +/* this will not return until a valid cmd is received */ +void +ipgdb_getpacket(char *buffer) +{ + unsigned char checksum, xmitcsum, ch, *c_ptr; + int count; + +/* while interface hasn't responded, do nothing */ +tryagain: + while (ipgdb_gotone == 0) { + DELAY(10000); +#ifdef IP_GDB_FXP + fxp_intr(ipgdb_ifp->if_softc); +#endif +#ifdef IP_GDB_SIS + sis_intr(ipgdb_ifp->if_softc); +#endif + /* make sure ARP requests are handled */ + arpintr(); + } + + ipgdb_gotone = 0; + + if (ipgdb_inbuf[0] != '$') + goto tryagain; + + c_ptr = ipgdb_inbuf; + ++c_ptr; /* skip over the $ */ + checksum = 0; + xmitcsum = -1; + count = 0; + + /* XXX 400 is gdb-stub's BUFMAX, deal with the ugliness */ + while (count < 400) + { + ch = *c_ptr & 0x7f; + ++c_ptr; + if (ch == '#') + break; + checksum = checksum + ch; + buffer[count] = ch; + count = count + 1; + } + buffer[count] = 0; + + if (ch == '#') + { + xmitcsum = hex(*c_ptr & 0x7f) << 4; + ++c_ptr; + xmitcsum += hex(*c_ptr & 0x7f); + ++c_ptr; + + if (checksum != xmitcsum) + { + /* send a - packet, ugh, Bad */ + ipgdb_putpacket("-"); + /* discard the packet */ + goto tryagain; + } else { + /* send a + packet, ugha, Good! */ + ipgdb_putpacket("+"); + + /* if a sequence char is present, reply the seq ID */ + /* tgilman - sequence stuff is deprecated */ + } /* else */ + } /* if */ +} + +/* + * ipgdb_forward() is called from net/if_ethersubr.c + * just before the schednetisr() call, if need be + */ +int +ipgdb_forward(m, ifp, eh) + struct mbuf *m; + struct ifnet *ifp; + struct ether_header *eh; +{ + register struct ip *ip_ptr; + register struct udphdr *uh; + int ip_hlen, ulen, ip_plen; + u_int data_size; + u_short sum; + + if (m->m_pkthdr.len < sizeof(struct ip)) { + return 0; + } + + if (m->m_len < sizeof (struct ip) && + (m = m_pullup(m, sizeof (struct ip))) == 0) { + return 0; + } + + ip_ptr = mtod(m, struct ip *); + + /* don't look at ip fragments */ + if(ip_ptr->ip_off!=0) { + return 0; + } + + /* determine if this packet is for the debugger */ + if (IP_VHL_V(ip_ptr->ip_vhl) != IPVERSION) { + return 0; + } + + /* need min header before we can check protocol type */ + ip_hlen = IP_VHL_HL(ip_ptr->ip_vhl) << 2; + if (ip_hlen < sizeof(struct ip)) { /* min header length */ + return 0; + } + + if (ip_hlen > m->m_len) { /* get the whole IP header */ + if ((m = m_pullup(m, ip_hlen)) == 0) { + return 0; + } + ip_ptr = mtod(m, struct ip *); + } + + /* + * although we haven't finished processing at the IP level + * peek at the protocol value so we can determine early + * if the packet is of interest. the debugger only + * wants UDP stuff, ignore everything else + */ + if (ip_ptr->ip_p != IPPROTO_UDP) {/* UDP? */ + return 0; + } + + /* this code is religiously stolen from, i mean *modeled after*, + * code from netinet/ip_input.c:line 317, ip_input() + */ + /* verify the ip header checksum */ + if(m->m_pkthdr.csum_flags & CSUM_IP_CHECKED) { + sum = !(m->m_pkthdr.csum_flags & CSUM_IP_VALID); + } else { + if (ip_hlen == sizeof(struct ip)) { + sum = in_cksum_hdr(ip_ptr); + } else { + sum = in_cksum(m, ip_hlen); + } + } + if (sum) { + return 0; + } + + /* sanity check the length of the ip packet */ + /* mbuf is too short for ip packet */ + ip_plen = ntohs(ip_ptr->ip_len); + + if(m->m_pkthdr.len < ip_plen) { + return 0; + } + + /* XXX kgdb will not work on machines that are doing IP + * forwarding -- need to check ip address to get this to work + * see "to forward or not to forward, p217, tcpip illustrated, vol. 2 + */ + + /* onto UPD level processing */ + /* checked protocol type above before checking ip header checksum + * and sanity checking the lengths + */ + /* now pulling from udp_usrreq.c:169 */ + + /* get the whole UDP header in the mbuf */ + if (m->m_len < ip_hlen + sizeof(struct udphdr)) { + if ((m = m_pullup(m, ip_hlen + sizeof(struct udphdr))) == 0) { + return 0; + } + ip_ptr = mtod(m, struct ip *); + } + uh = (struct udphdr *)((caddr_t)ip_ptr + ip_hlen); + /* now that we've got the udp header, check port number */ + if (ipgdb_getns(&uh->uh_dport) != IPGDBPORT ) { + return 0; + } + + /* check the UDP length agains the mbuf length + * and the IP length. + * + * at this point we've determined the the IP data is + * ours and we can do with it what we wish, + * if its bad we should be able to drop it + * + * XXX could probably update UDP stats here also + */ + /* strip the IP options so the we can do the checksum */ + /* trim the packet if longer than we expect */ + if(m->m_pkthdr.len > ip_plen) { + /* if m_len == m_pkthdr.len, the mbuf is simple, directly modify len */ + if(m->m_len == m->m_pkthdr.len) { + m->m_len = ip_plen; + m->m_pkthdr.len = ip_plen; + } else { + m_adj(m, ip_plen - m->m_pkthdr.len); + } + } + + if(ip_hlen > sizeof(struct ip)) { + ip_stripoptions(m, (struct mbuf *)0); + ip_hlen = sizeof(struct ip); + } + ip_ptr = mtod(m, struct ip *); + uh = (struct udphdr *)((caddr_t)ip_ptr + ip_hlen); + + ulen = ntohs((u_short)uh->uh_ulen); + if((ip_plen - sizeof(struct ip)) != ulen) { + if(ulen > ip_plen || ulen < sizeof(struct udphdr)) { + /* drop the packet */ + m_freem(m); + return 1; + } + m_adj(m, ulen - (ip_plen-sizeof(struct ip))); + } + + /* + * do a UDP checksum to further verify the UDP packet + */ + if (uh->uh_sum) { + if (m->m_pkthdr.csum_flags & CSUM_DATA_VALID) { + if (m->m_pkthdr.csum_flags & CSUM_PSEUDO_HDR) { + uh->uh_sum = m->m_pkthdr.csum_data; + } else { + uh->uh_sum = in_pseudo(ip_ptr->ip_src.s_addr, + ip_ptr->ip_dst.s_addr, + htonl((u_short)ulen + + m->m_pkthdr.csum_data + IPPROTO_UDP)); + } + uh->uh_sum ^= 0xffff; + } else { + bzero(((struct ipovly *)ip_ptr)->ih_x1, 9); + ((struct ipovly *)ip_ptr)->ih_len = uh->uh_ulen; + uh->uh_sum = in_cksum(m, ulen + sizeof (struct ip)); + } + if (uh->uh_sum) { + m_freem(m); + return 1; + } + } + + ip_hlen += sizeof(struct udphdr); + m_adj(m, ip_hlen); + data_size = ulen - sizeof(struct udphdr); + m_copydata(m,0,data_size,(caddr_t)ipgdb_inbuf); + /* cap off the buffer */ + ipgdb_inbuf[data_size] = '\000'; + + if (ipgdb_connected == 0) { /* first time? */ + /* if we're not connected, this packet might not be for */ + /* us. check for the expected first packet. */ + if (ipgdb_inbuf[0] != '+') { /* not ours */ + m_freem(m); + return 1; + } + ipgdb_ack_packet = 1; /* just checked this */ + /* record some information about our session */ + ipgdb_ifp = ifp; + ipgdb_ip_us.sin_port = uh->uh_dport; + ipgdb_ip_us.sin_addr = ip_ptr->ip_dst; + ipgdb_ip_them.sin_port = uh->uh_sport; + ipgdb_ip_them.sin_addr = ip_ptr->ip_src; + + /* save off the ethernet addrs */ + ipgdb_copy(eh->ether_dhost, ipgdb_ether_us, sizeof(eh->ether_dhost)); + ipgdb_copy(eh->ether_shost, ipgdb_ether_them, sizeof(eh->ether_shost)); + +#if 0 + /* prepare for callback from driver */ + ipgdb_connected = 2; + m_freem(m); + return 1; +#else + /* make note of our connectedness */ + ipgdb_connected = 1; + + /* setup code path to drop immediately into + * remote debugging session + */ + boothowto |= RB_GDB; /* causes Debugger() to go remote */ + m_freem(m); + Debugger("remote debugging initiated"); + return 1; +#endif + } + + /* note ack/+ packets now */ + if (ipgdb_inbuf[0] == '+') { + ipgdb_ack_packet = 1; + } else { + ipgdb_gotone = 1; + } + + /* special case: user 'c'ontinued, then CNTL-C'd */ + if (ipgdb_inbuf[0] == 0x3) { + ipgdb_gotone = 0; + m_freem(m); +#if 0 + ipgdb_connected = 2; /* force driver to callback */ +#else + Debugger("break into remote debugger"); +#endif + return 1; + } + + /* free up the mbuf */ + m_freem(m); + return 1; +} + diff -ruN 4.5/ipgdb/ipgdb.h sys/ipgdb/ipgdb.h --- 4.5/ipgdb/ipgdb.h Wed Dec 31 16:00:00 1969 +++ sys/ipgdb/ipgdb.h Thu Feb 28 17:25:31 2002 @@ -0,0 +1,97 @@ +/* + * Copyright (c) 2002 + * Panasas, Inc. All rights reserved. + * + * Some of this code is derived from FreeBSD sources. See Copyright + * below. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by Panasas, Inc. + * 4. The name of Panasas, Inc. may not be used to endorse or promote + * products derived from this software without specific prior written + * permission. + * + * THIS SOFTWARE IS PROVIDED BY PANASAS, INC. ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL PANASAS, INC. BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ +/* + * Copyright (c) 1980, 1986, 1991, 1993 + * The Regents of the University of California. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ +/* + * ipgdb.h + * + * udp-based debugger guts for use by other kernel parts + * + */ + +#ifndef _IPGDB_H +#define _IPGDB_H + +#include +#include + +#define IPGDBPORT 4 /* debugging port */ + +/* gdb-stub uses put/getpacket */ +void ipgdb_putpacket_add_wrapper(char *buffer); +void ipgdb_putpacket(char *snd_buf); +void ipgdb_getpacket(char *buffer); + +/* some prototypes for ipgdb */ +void ipgdb_fillbuff(const char *src); +int ipgdb_forward(struct mbuf *m, struct ifnet *ifp, struct ether_header *eh); + +extern int ipgdb_connected; + +/* help functions to prevent debugger lock via breakpoint */ +char * ipgdb_strcpy(char *dst, const char *src); + +#endif /* _IPGDB_H */ + diff -ruN 4.5/kern/kern_shutdown.c sys/kern/kern_shutdown.c --- 4.5/kern/kern_shutdown.c Thu Feb 21 11:15:10 2002 +++ sys/kern/kern_shutdown.c Thu Jun 20 16:03:18 2002 @@ -43,6 +43,7 @@ #include "opt_hw_wdog.h" #include "opt_panic.h" #include "opt_show_busybufs.h" +#include "opt_ip_gdb.h" #include #include @@ -590,6 +591,9 @@ #if defined(DDB) if (debugger_on_panic) +#if defined IP_GDB + boothowto |= RB_GDB; +#endif Debugger ("panic"); #endif boot(bootopt); diff -ruN 4.5/modules/fxp/Makefile sys/modules/fxp/Makefile --- 4.5/modules/fxp/Makefile Tue Dec 4 12:01:53 2001 +++ sys/modules/fxp/Makefile Sat Jun 22 17:46:55 2002 @@ -3,6 +3,7 @@ .PATH: ${.CURDIR}/../../dev/fxp KMOD = if_fxp SRCS = if_fxp.c opt_bdg.h device_if.h bus_if.h pci_if.h miibus_if.h +SRCS += opt_ip_gdb_fxp.h KMODDEPS = miibus .include diff -ruN 4.5/net/if_ethersubr.c sys/net/if_ethersubr.c --- 4.5/net/if_ethersubr.c Wed Apr 3 21:51:55 2002 +++ sys/net/if_ethersubr.c Sat Jun 22 16:19:52 2002 @@ -40,6 +40,7 @@ #include "opt_ipx.h" #include "opt_bdg.h" #include "opt_netgraph.h" +#include "opt_ip_gdb.h" #include #include @@ -60,6 +61,10 @@ #include #include +#ifdef IP_GDB +#include +#endif + #if defined(INET) || defined(INET6) #include #include @@ -552,6 +557,10 @@ switch (ether_type) { #ifdef INET case ETHERTYPE_IP: +#ifdef IP_GDB + if (ipgdb_forward(m, ifp, eh)) + return; +#endif /* IP_GDB */ if (ipflow_fastforward(m)) return; schednetisr(NETISR_IP); diff -ruN 4.5/netinet/if_ether.c sys/netinet/if_ether.c --- 4.5/netinet/if_ether.c Wed Mar 27 08:40:59 2002 +++ sys/netinet/if_ether.c Sat Jun 22 17:11:45 2002 @@ -71,6 +71,8 @@ #include #include +#include "opt_ip_gdb.h" + #define SIN(s) ((struct sockaddr_in *)s) #define SDL(s) ((struct sockaddr_dl *)s) @@ -118,7 +120,11 @@ static void arp_rtrequest __P((int, struct rtentry *, struct rt_addrinfo *)); static void arprequest __P((struct ifnet *, struct in_addr *, struct in_addr *, u_char *)); -static void arpintr __P((void)); +#ifdef IP_GDB + void arpintr __P((void)); +#else +static void arpintr __P((void)); +#endif static void arptfree __P((struct llinfo_arp *)); static void arptimer __P((void *)); static struct llinfo_arp @@ -492,7 +498,11 @@ * Common length and type checks are done here, * then the protocol-specific routine is called. */ +#ifdef IP_GDB +void +#else static void +#endif arpintr() { register struct mbuf *m; --W/nzBZO5zC0uMSeA-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 2: 9:43 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 647B637B400 for ; Sat, 7 Sep 2002 02:09:41 -0700 (PDT) Received: from relay01.cablecom.net (relay01.cablecom.net [62.2.33.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65EEF43E7B for ; Sat, 7 Sep 2002 02:09:40 -0700 (PDT) (envelope-from hanspeter_roth@hotmail.com) Received: from gicco.cablecom.ch (dclient80-218-73-118.hispeed.ch [80.218.73.118]) by relay01.cablecom.net (8.12.5/8.12.5/SOL/AWF/MXRELAY/20020820) with ESMTP id g8799c20057057; Sat, 7 Sep 2002 11:09:38 +0200 (CEST) (envelope-from hanspeter_roth@hotmail.com) Received: (from idefix@localhost) by gicco.cablecom.ch (8.11.6/8.11.6) id g8799aV00495; Sat, 7 Sep 2002 11:09:36 +0200 (CEST) (envelope-from hanspeter_roth@hotmail.com) Date: Sat, 7 Sep 2002 11:09:36 +0200 From: Hanspeter Roth To: freebsd-hackers@FreeBSD.ORG Cc: Christian Zander Subject: Re: interrupting the remote kernel Message-ID: <20020907110936.A386@gicco.cablecom.ch> Reply-To: freebsd-hackers@FreeBSD.ORG Mail-Followup-To: freebsd-hackers@FreeBSD.ORG, Christian Zander References: <20020906220033.A1830@gicco.cablecom.ch> <20020907094726.K652@chronos> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020907094726.K652@chronos>; from zander@minion.de on Sat, Sep 07, 2002 at 09:47:26AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sep 07 at 09:47, Christian Zander spoke: > What I found to work well is remote GDB debugging with the UDP > wrapper (ip-gdb), it responds to CTRL-C as expected. Is there a description available about how to configure/setup the target kernel? Where is ip-gdb available? -Hanspeter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 2:45:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 4872937B400; Sat, 7 Sep 2002 02:45:38 -0700 (PDT) Date: Sat, 7 Sep 2002 02:45:38 -0700 From: Juli Mallett To: hackers@FreeBSD.org Subject: siginfo_t, the signal stack, svr4_sendsig (i386), and the ever unwinding ball of yarn Message-ID: <20020907024538.A67757@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Okay so I've finally wrapped my head around the bit of code that I need, and I find out that despite FreeBSD having a "native" siginfo_t format, it's essentially UNUSED! Here's the deal, I need to be able to write something like trapsignal(), but generalised, call it siginfosignal(), and pretend that instead of 'code', it takes a 'siginfo_t', and posts the signal, blah blah blah, but tells the sendsig code to use the supplied siginfo_t, instead of building one (there seems to be a bug in that, anyway - the first entry into the signal handler seems to have some extra bits in si_code), and so on, and would abstract the interface cleanly. It's easy to map trapsignal() to just build up an si_code = code, and so on, and it's easy not to break anything internally, except stuff with intimate knowledge of the machdep sendsig(), but they could change to the NEW api anyway. The problem is I just don't have my head wrapped around the format of the signal stack, or how to implant/copyout as I need to - it seems as if NOTHING uses siginfo, except the i386 svr4 compatability code, and a few other consumers which don't really use it. Can anyone help me get my head around this so I can modify every one of the blasted md sendsig() routines, and try to do this as I see "right", or (please god) point me to a way of doing it with the existing stuff? I'd love to not make stuff MORE MD than it already is, and I'd further love to abstract this all nicely, but I'm not sure what I can do, short of what I outlined above (vaguely). I know I can get around this in a KSE world with upcalls and moving everything to the UTS, but right now I'm doing this in terms of signals as I have to develop on 4.x and OpenBSD, rather than CURRENT, and I'm seeing that we have a huge gap, with some tape over it that says "siginfo_t", but it's really just a big gap with tape over it (excuse the crap metaphors, I'm stretched far too thin). Thanks, juli. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 2:56:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 931) id 5CD9337B400; Sat, 7 Sep 2002 02:56:10 -0700 (PDT) Date: Sat, 7 Sep 2002 02:56:10 -0700 From: Juli Mallett To: Alexey Dokuchaev Cc: hackers@freebsd.org Subject: Re: Usenix 2002 FreeBSD Developer Summit III -- why no oggs? Message-ID: <20020907025610.A68668@FreeBSD.org> References: <20020906084959.A6251@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020906084959.A6251@regency.nsu.ru>; from danfe@regency.nsu.ru on Fri, Sep 06, 2002 at 08:49:59AM +0700 Organisation: The FreeBSD Project X-Alternate-Addresses: , , , , X-Towel: Yes X-LiveJournal: flata, jmallett X-Negacore: Yes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * De: Alexey Dokuchaev [ Data: 2002-09-05 ] [ Subjecte: Usenix 2002 FreeBSD Developer Summit III -- why no oggs? ] > Hi! > > I've read the notes as of 2 September, 2002 from the USENIX ATC 2002 FreeBSD Developer > Summit, which were made available recently. As a very good addition to > them, I suggest putting online some .oggs (or .mp3s) next time, with recorded > speeches, just like guys from recent linux kernel summit did (ksmp3rep.sourceforge.net)? > > Sounds like a good idea to me. Opinions? > > ./danfe We've had MP3s and an MP3 stream for (at least) the last two summits, the problem comes down to one of enormous size. -- Juli Mallett | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger jmallett@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 3: 6:37 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D32137B400; Sat, 7 Sep 2002 03:06:35 -0700 (PDT) Received: from mail.nsu.ru (mx.nsu.ru [193.124.215.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id E029643E77; Sat, 7 Sep 2002 03:06:32 -0700 (PDT) (envelope-from danfe@regency.nsu.ru) Received: from drweb by mail.nsu.ru with drweb-scanned (Exim 3.20 #1) id 17ncTx-0001M4-00; Sat, 07 Sep 2002 17:06:25 +0700 Received: from regency.nsu.ru ([193.124.210.26]) by mail.nsu.ru with esmtp (Exim 3.20 #1) id 17ncTx-0001Da-00; Sat, 07 Sep 2002 17:06:25 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.12.4/8.12.4) with ESMTP id g87A7t5G063998; Sat, 7 Sep 2002 17:07:55 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.12.4/8.12.4/Submit) id g87A7kl3063949; Sat, 7 Sep 2002 17:07:46 +0700 (NOVST) Date: Sat, 7 Sep 2002 17:07:46 +0700 From: Alexey Dokuchaev To: Juli Mallett Cc: hackers@freebsd.org Subject: Re: Usenix 2002 FreeBSD Developer Summit III -- why no oggs? Message-ID: <20020907170745.A62120@regency.nsu.ru> References: <20020906084959.A6251@regency.nsu.ru> <20020907025610.A68668@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020907025610.A68668@FreeBSD.org>; from jmallett@freebsd.org on Sat, Sep 07, 2002 at 02:56:10AM -0700 X-Envelope-To: jmallett@freebsd.org, hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Sep 07, 2002 at 02:56:10AM -0700, Juli Mallett wrote: > * De: Alexey Dokuchaev [ Data: 2002-09-05 ] > [ Subjecte: Usenix 2002 FreeBSD Developer Summit III -- why no oggs? ] > > Hi! > > > > I've read the notes as of 2 September, 2002 from the USENIX ATC 2002 FreeBSD Developer > > Summit, which were made available recently. As a very good addition to > > them, I suggest putting online some .oggs (or .mp3s) next time, with recorded > > speeches, just like guys from recent linux kernel summit did (ksmp3rep.sourceforge.net)? > > > > Sounds like a good idea to me. Opinions? > > > > ./danfe > > We've had MP3s and an MP3 stream for (at least) the last two summits, the > problem comes down to one of enormous size. Uhm.. Still, is it available on the Net somewhere? Outbound traffic should not cost anything with any ISP, so essentially it sounds like big size is only my problem. :-)) ./danfe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 3:34:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8849A37B400 for ; Sat, 7 Sep 2002 03:34:24 -0700 (PDT) Received: from relay01.cablecom.net (relay01.cablecom.net [62.2.33.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9234143E65 for ; Sat, 7 Sep 2002 03:34:23 -0700 (PDT) (envelope-from hanspeter_roth@hotmail.com) Received: from gicco.cablecom.ch (dclient80-218-73-118.hispeed.ch [80.218.73.118]) by relay01.cablecom.net (8.12.5/8.12.5/SOL/AWF/MXRELAY/20020820) with ESMTP id g87AYL20082285 for ; Sat, 7 Sep 2002 12:34:21 +0200 (CEST) (envelope-from hanspeter_roth@hotmail.com) Received: (from idefix@localhost) by gicco.cablecom.ch (8.11.6/8.11.6) id g87AYLQ00903 for freebsd-hackers@FreeBSD.ORG; Sat, 7 Sep 2002 12:34:21 +0200 (CEST) (envelope-from hanspeter_roth@hotmail.com) Date: Sat, 7 Sep 2002 12:34:21 +0200 From: Hanspeter Roth To: freebsd-hackers@FreeBSD.ORG Subject: Re: interrupting the remote kernel Message-ID: <20020907123421.A827@gicco.cablecom.ch> Reply-To: freebsd-hackers@FreeBSD.ORG Mail-Followup-To: freebsd-hackers@FreeBSD.ORG References: <20020906220033.A1830@gicco.cablecom.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from nate@root.org on Fri, Sep 06, 2002 at 05:17:07PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sep 06 at 17:17, Nate Lawson spoke: > You can do this by connecting a second serial cable for a console between > your host and target or by using the remotechat option and a single cable. > Once you have the serial console, option ALT_BREAK_TO_DEBUGGER allows you > to initiate a break using your terminal emulator's "send break" command. My remote host is a laptop with only one sio port. So if it would be possible with a single serial connection I'd appreciate it. I have played a little with remotechat but with strange results. If I set remotechat before `target remote /dev/cuaa0' the latter fails. If I set remotechat after `target remote' but before continuing ctl-alt-esc on the target host doesn't work anymore. Only garbage appears in the remote gdb. Also ctl-c in gdb doesn't achieve anything. Only after three ctl-cs I can detach gdb. I have now also added option ALT_BREAK_TO_DEBUGGER but that doesn't help either nor does the sequence CR~^b in gdb. (I want to interrupt the target host while X is active.) > If the hang is not a system hang, the console break will have an effect. > But if the kernel is so hung that the keyboard doesn't work, the remote > serial console will not do you any better. In this case you need a box > with a real console (i.e. Sun). I won't by a Sun. I'm just hoping the hang is not a system hang. :-) -Hanspeter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 5:24:26 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76B4037B400 for ; Sat, 7 Sep 2002 05:24:21 -0700 (PDT) Received: from dmlb.org (pc1-cmbg2-6-cust106.cam.cable.ntl.com [80.4.4.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6FEF43E72 for ; Sat, 7 Sep 2002 05:24:20 -0700 (PDT) (envelope-from dmlb@dmlb.org) Received: from slave.my.domain ([192.168.200.39]) by dmlb.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 3.36 #1) id 17necc-000GGl-00; Sat, 07 Sep 2002 13:23:30 +0100 Received: from dmlb by slave.my.domain with local (Exim 3.36 #1) id 17necc-00041S-00; Sat, 07 Sep 2002 13:23:30 +0100 Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020906.235110.108188889.imp@bsdimp.com> Date: Sat, 07 Sep 2002 13:23:30 +0100 (BST) From: Duncan Barclay To: "M. Warner Losh" , bms@spc.org Subject: Re: PCMCIA questions: mapping attribute and common memory? Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 07-Sep-2002 M. Warner Losh wrote: > In message: <20020906093215.GI15218@spc.org> > Bruce M Simpson writes: >: Thanks for your informative response. > > Sure. Sorry for the long delay on this one. I wanted to give a good > answer rather than a fast one. I'm just clarifying a couple of the questions Warner raises. I wrote the ray driver. [snipped[ >: Once I've allocated the window as a resource, how would I go about accessing >: that memory directly? Would I need to establish a page mapping? > > OK. Lemme talk with code (which I've grabbed from ray_res_alloc_am) > > sc->am_rid = RAY_AM_RID; > sc->am_res = bus_alloc_resource(sc->dev, SYS_RES_MEMORY, > &sc->am_rid, 0UL, ~0UL, 0x1000, RF_ACTIVE); Note that the 0x1000 is the size of the map requested. The code doesn't use the CIS to set the AM map up. It's all hardcoded. In contrast, pccardd set the CM map up for you. > error = CARD_SET_MEMORY_OFFSET(device_get_parent(sc->dev), sc->dev, > sc->am_rid, 0, NULL); > error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, > SYS_RES_MEMORY, sc->am_rid, PCCARD_A_MEM_ATTR); > error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, > SYS_RES_MEMORY, sc->am_rid, PCCARD_A_MEM_8BIT); > > (I'm not sure why the ray driver doesn't combine the last two calls). /sys/pccard/pcic.c:pcic_set_res_flags() doesn't actually treat the flags as a bit mask, it just uses a switch to test the arguments. The PCCARD_A_MEM_8BIT might not be needed for your cards. > The rid is 3. pccardd abuses window 0 (and the comments in the > ray driver say 1 also, which may be possible). We really should use > window 4 for the CIS, but that's too big a change (and would break > support for media chipsets, which have only one memory map, but those > are only on early pc98 laptops). FYI, the abuses is that sometimes, pccardd and pccardc will remap window 0 to do things, even if it is use by a driver. > Anyway, you pick the window that you want to use. You the map it. To > manage where in the memory you'd like to map it, you set the offset. > To make it the attribute memory, we set the resoruce flags. Ditto > with 8 bit. Allocating the common memory would be similar. > > In the ray driver, it uses rid 0 for the common memory so it can get > the size of the memory. So that code looks like: > > u_long start, count, end; > sc->cm_rid = RAY_CM_RID; > start = bus_get_resource_start(sc->dev, SYS_RES_MEMORY, sc->cm_rid); > count = bus_get_resource_count(sc->dev, SYS_RES_MEMORY, sc->cm_rid); > end = start + count - 1; > sc->cm_res = bus_alloc_resource(sc->dev, SYS_RES_MEMORY, > &sc->cm_rid, start, end, count, RF_ACTIVE); > error = CARD_SET_MEMORY_OFFSET(device_get_parent(sc->dev), sc->dev, > sc->cm_rid, 0, NULL); > error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, > SYS_RES_MEMORY, sc->cm_rid, PCCARD_A_MEM_COM); > error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, > SYS_RES_MEMORY, sc->cm_rid, PCCARD_A_MEM_8BIT); > > which is very similar. This only works because the rid is 0. I'm not > sure what the CIS of the ray cards look like (my ray cards aren't > easily accessible at the moment). The code looks similar but the underlying reasons are different. pccardd has already set up the CM from its parsing of the CIS. This code just ensures that mapping is correct. But the ray cards use 8bit memory and that info isn't in the CIS - so I have to reset the window. If your cards are 16bits, then you won't need to do any of this. Whereas, the AM code above had to create a new mapping for the AM as pccardd doesn't leave that around for the driver (this is all OLDCARD). There is a raylink CIS at http://www.ragnet.demon.co.uk/ray_cis.txt Duncan -- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@dmlb.org | the alcoholics, and the permanently stoned. dmlb@freebsd.org| Steven King To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 5:36:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 062F137B400 for ; Sat, 7 Sep 2002 05:36:02 -0700 (PDT) Received: from insomnia.spc.org (insomnia.spc.org [195.224.94.183]) by mx1.FreeBSD.org (Postfix) with SMTP id 28C4F43E42 for ; Sat, 7 Sep 2002 05:36:01 -0700 (PDT) (envelope-from bms@insomnia.spc.org) Received: (qmail 27822 invoked by uid 1031); 7 Sep 2002 12:34:10 -0000 Date: Sat, 7 Sep 2002 13:34:10 +0100 From: Bruce M Simpson To: "M. Warner Losh" Cc: freebsd-hackers@FreeBSD.ORG Subject: OLDCARD function interrupt routing -- patch. Message-ID: <20020907123409.GQ15218@spc.org> Mail-Followup-To: Bruce M Simpson , "M. Warner Losh" , freebsd-hackers@FreeBSD.ORG References: <20020905191546.GF15218@spc.org> <20020905.145936.39157187.imp@bsdimp.com> <20020906093215.GI15218@spc.org> <20020906.235110.108188889.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline In-Reply-To: <20020906.235110.108188889.imp@bsdimp.com> User-Agent: Mutt/1.3.28i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Warner, Thanks again for making all of that much more clear. Since I originally composed this mail I've hacked out a patch to OLDCARD to bit-bang the registers on the 5C475E. I also mapped out which IRQs were actually in use and which were not; and manually changed the 'irq' entry in /etc/pccard.conf to reflect this. It looks as though being able to flip function routing separately from CSC routing is what does the trick, correct me if I'm wrong; things have suddenly decided to work. pccard0: Assigning gpr400: io 0x300-0x31f irq 3 mem 0xd4000-0xd4fff - I've tested with a CDROM drive and a CF card, as well as a ZoomAir wireless card. The offending GPR400 card gets its irq from pccardd just fine now. Aside from some PRISM2 bitching when placed into monitor mode (sometimes to be expected), everything seems to be fine. - I've placed the datasheet online in case anyone needs to grab it for reference: http://www.incunabulum.com/tmp/5C475E.pdf - Please see patch (and whine) attached. If I'm barking up the wrong tree totally, comments would be appreciated. Thanks! Now I'll tackle that nasty driver. BMS --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pccard-func-isa-routing.patch" diff -uNr pccard.orig/i82365.h pccard/i82365.h --- pccard.orig/i82365.h Wed Jul 31 21:01:10 2002 +++ pccard/i82365.h Sat Sep 7 03:32:48 2002 @@ -146,6 +146,7 @@ #define PCIC_IOCARD 0x20 #define PCIC_MEMCARD 0x00 #define PCIC_INTR_ENA 0x10 /* PCI CSC Interrupt enable */ +#define PCIC_INTR_MASK 0x0F /* Ricoh: Mask for routed ISA IRQ */ /* For the Card Status Change register (PCIC_STAT_CHG) */ #define PCIC_CDTCH 0x08 /* Card Detect Change */ diff -uNr pccard.orig/pcic_pci.c pccard/pcic_pci.c --- pccard.orig/pcic_pci.c Wed Jul 31 21:01:11 2002 +++ pccard/pcic_pci.c Sat Sep 7 13:50:48 2002 @@ -73,10 +73,20 @@ * routing doesn't work. It is purposely vague and undocumented * at the moment. Sadly, this seems to be needed way too often. */ -static int pcic_intr_path = (int)pcic_iw_pci; -TUNABLE_INT("hw.pcic.intr_path", &pcic_intr_path); -SYSCTL_INT(_hw_pcic, OID_AUTO, intr_path, CTLFLAG_RD, &pcic_intr_path, 0, - "Which path to send the interrupts over."); +static int pcic_csc_intr_path = (int)pcic_iw_pci; +TUNABLE_INT("hw.pcic.csc_intr_path", &pcic_csc_intr_path); /* XXX */ +SYSCTL_INT(_hw_pcic, OID_AUTO, csc_intr_path, CTLFLAG_RD, +&pcic_csc_intr_path, 0, "Which path to send card services interrupts over."); + +static int pcic_func_intr_path = (int)pcic_iw_pci; +TUNABLE_INT("hw.pcic.func_intr_path", &pcic_func_intr_path); +SYSCTL_INT(_hw_pcic, OID_AUTO, func_intr_path, CTLFLAG_RD, +&pcic_func_intr_path, 0, "Which path to send function interrupts over."); + +static int pcic_func_irq = 0; +TUNABLE_INT("hw.pcic.func_irq", &pcic_func_irq); +SYSCTL_INT(_hw_pcic, OID_AUTO, func_irq, CTLFLAG_RD, +&pcic_func_irq, 0, "Override IRQ for routing of function interrupt via ISA. "); static int pcic_init_routing = 0; TUNABLE_INT("hw.pcic.init_routing", &pcic_init_routing); @@ -575,8 +585,19 @@ static void pcic_pci_ricoh_init(device_t dev) { - u_int16_t brgcntl; - u_int32_t device_id = pci_get_devid(dev); +#if defined(PCIC_ISA_FUNC_ROUTING) + struct pcic_softc *sc; + struct pcic_slot *sp; + struct resource *res; + u_int16_t intgen; +#endif + u_int16_t brgcntl; + u_int32_t device_id = pci_get_devid(dev); + +#if defined(PCIC_ISA_FUNC_ROUTING) + sc = (struct pcic_softc *) device_get_softc(dev); + sp = &sc->slots[0]; +#endif switch (device_id) { case PCI_DEVICE_ID_RICOH_RL5C465: @@ -592,6 +613,38 @@ break; } pcic_pci_cardbus_init(dev); + +#if defined(PCIC_ISA_FUNC_ROUTING) + /* + * Force ISA interrupt routing for the function interrupt, + * and not the CSC interrupt. + */ + if ((sc->func_route == pcic_iw_isa) && pcic_func_irq != 0) { + int rid; + + /* Allocate the ISA function IRQ. This never gets freed. */ + res = bus_alloc_resource(dev, SYS_RES_IRQ, &rid, + pcic_func_irq, pcic_func_irq, 1, RF_ACTIVE); + if (!res) + panic("Could not allocate ISA function IRQ!\N"); + + device_printf(dev, "using ISA function irq %d\n", + pcic_func_irq); + + pcic_pci_gen_func(sp, pcic_iw_isa); + intgen = sp->getb(sp, PCIC_INT_GEN); + intgen &= ~(PCIC_INTR_MASK); + intgen |= pcic_func_irq; + sp->putb(sp, PCIC_INT_GEN, intgen); + + /* + * XXX: Blindly catch any interrupts which might have been + * generated as a result of writing to PCIC_INT_GEN. + */ + bus_space_write_4(sp->bst, sp->bsh, CB_SOCKET_EVENT, + 0xffffffff); + } +#endif } /* @@ -1057,7 +1110,7 @@ * for an explaination of ISA vs PCI interrupts. XXX Might be other * special cases as well. */ - if (pcic_intr_path == pcic_iw_pci && + if (pcic_csc_intr_path == pcic_iw_pci && device_id != PCI_DEVICE_ID_PCIC_CLPD6729) { rid = 0; #ifdef __i386__ @@ -1238,8 +1291,8 @@ sc->flags = PCIC_CARDBUS_POWER; } sp->slt = (struct slot *) 1; - sc->csc_route = pcic_intr_path; - sc->func_route = pcic_intr_path; + sc->csc_route = pcic_csc_intr_path; + sc->func_route = pcic_func_intr_path; stat = bus_space_read_4(sp->bst, sp->bsh, CB_SOCKET_STATE); sc->cd_present = (stat & CB_SS_CD) == 0; } --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="whine.txt" It appears to be academic for the time being, though, as pccardd can't allocate the resources the card needs. On my Sony Vaio, when the ACPI bios is told to configure non-boot devices (Plug and Play OS = NO), it muxes everything onto IRQ 9. This includes the pcic0 device (both for card services, and for function). Unfortunately the device I'm working with doesn't support IRQ 9. Now I see that some good work had been done around the problem of PCI and ISA interrupt routing. When I put the bridge on this system into polling mode, and run pccardd, the box hangs (forcing a break into DDB reveals that other interrupts are still being serviced, but pccardd is hanging). I've been doing my testing from single user with filesystems except /var mounted readonly, /var also has softupdates enabled (4.6-STABLE). I managed to pull the data sheet for the Ricoh 5C475E controller. Apparently setting the CB_BCR_INT_EXCA bit on this variant allows the IREQ#/CREQ# line for 16-bit cards to be routed to an ISA IRQ. I assume this is what sc->func_route in pcic*.c refers to. My guess is that the Win2k cardbus driver has enough smarts to set things up in this way, as it allocates IRQ 7 for the 16-bit device, even though the cardbus controller itself is sharing IRQ 9. However, without being able to snapshot registers, I can't be entirely sure. I realize that I'm doing this work on OLDCARD, but I'm quite desperate to get things working, so I've attached a patch with what I'm currently doing. --rS8CxjVDS/+yyDmU-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 7:12:56 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2CA837B400 for ; Sat, 7 Sep 2002 07:12:53 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A11843E65 for ; Sat, 7 Sep 2002 07:12:51 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g87ECVOo060140; Sat, 7 Sep 2002 10:12:31 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 7 Sep 2002 10:12:30 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Seva Tonkonoh Cc: freebsd-hackers@freebsd.org Subject: Re: intermezzo? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 5 Sep 2002, Seva Tonkonoh wrote: > I have recently come across an old little discussion about InterMezzo. > I 've got the impression that it wasn't really welcome to FreeBSD. > > Just curious if something similar has been done for FreeBSD, or if > someone is working on such thing. I am actually looking for an MS > research project topic and Intermezzo seemed to be an interesting > possibility. Other suggestions would be also helpful. I had dinner with Peter Braam a few months ago, and should probably have inquired about it then, but we were rather caught up in other conversations. Given that it's follow-on work to the Coda work, and Coda runs on FreeBSD, the changes are pretty good the design would work on FreeBSD, although the kernel code certainly wouldn't. The devil is always in the details, of course, and given that no one has yet found the motivation or time to do a port, there are either a lot of details, not much interest, or no resources for the port :-). The good news is that if the Intermezzo design is as one would expect, the userland component should probably port with relative ease between platforms. Since InterMezzo is open source and research, my suspicion is that given appropriate investment of time or money, a port would be forthcoming with relative ease. Integration back in to FreeBSD's base operating system code would be (as pointed out elsewhere in this thread) limited for license reasons, but nothing says it can't be in our third party ports/packages section which is rife with variety of licenses. I would personally be very interested in seeing a port done, but don't have any resources to make it happen at this point. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 7:15: 3 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0C1A37B400; Sat, 7 Sep 2002 07:14:54 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C419243E6E; Sat, 7 Sep 2002 07:14:52 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g87EEWOo060353; Sat, 7 Sep 2002 10:14:32 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 7 Sep 2002 10:14:32 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: developers@FreeBSD.org, hackers@FreeBSD.org Subject: Request for submissions: FreeBSD Bi-Monthly Development Status Report (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Reminder... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories ---------- Forwarded message ---------- Date: Wed, 4 Sep 2002 12:19:38 -0400 (EDT) From: Robert Watson To: hackers@FreeBSD.org, developers@FreeBSD.org Subject: Request for submissions: FreeBSD Bi-Monthly Development Status Report This is a solicitation for submissions for the July 2002 - August 2002 FreeBSD Bi-Monthly Development Status Report. All submissions are due by September 13, 2002. Submissions should be made by filling out the template found at: http://www.FreeBSD.org/news/status/report-sample.xml Submissions must then be e-mailed to the following address: robert+freebsd.monthly@cyrus.watson.org For automatic processing. Reports must be submitted in the XML format described, or they will be silently dropped. Submissions made to other e-mail addresses will be ignored. If more than one report is submitted for a project, the latest instance will be used. Status reports should be submitted once per project, although project developers may choose to submit additional reports on specific sub-projects of substantial size. Status reports are typically one or two short paragraphs, but the text may be up to 20 lines in length. Submissions are welcome on a variety of topics relating to FreeBSD, including development, documentation, advocacy, and development processes. Submitting developer status reports help maintain an important link between FreeBSD developers, as well as a link to the user and sponsor communities. By submitting a report, you help share information about the rapid progress made by the project, making it easier for advocates to point at the excellent work that's being done! Prior status reports may be viewed at: http://www.FreeBSD.org/news/status/ Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 7:52:17 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B0BE37B400 for ; Sat, 7 Sep 2002 07:52:15 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88EC143E42 for ; Sat, 7 Sep 2002 07:52:14 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.4/8.12.4) with SMTP id g87EpsOo063892; Sat, 7 Sep 2002 10:51:54 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 7 Sep 2002 10:51:53 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alexey Dokuchaev Cc: hackers@freebsd.org Subject: Re: Usenix 2002 FreeBSD Developer Summit III -- why no oggs? In-Reply-To: <20020906084959.A6251@regency.nsu.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 6 Sep 2002, Alexey Dokuchaev wrote: > I've read the notes as of 2 September, 2002 from the USENIX ATC 2002 > FreeBSD Developer Summit, which were made available recently. As a very > good addition to them, I suggest putting online some .oggs (or .mp3s) > next time, with recorded speeches, just like guys from recent linux > kernel summit did (ksmp3rep.sourceforge.net)? > > Sounds like a good idea to me. Opinions? Recordings were made by Josef Karthauser (who generated the webcast from our teleconference bridge). He also did the recordings for previous developer summits. I'm not sure what his distribution plans are, but you could drop him an e-mail and inquire. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 7:52:42 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1799737B400; Sat, 7 Sep 2002 07:52:40 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEF2143E42; Sat, 7 Sep 2002 07:52:39 -0700 (PDT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17ngwe-0005y1-00; Sat, 07 Sep 2002 07:52:20 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Julian Elischer Cc: Poul-Henning Kamp , Nate Lawson , Bruce M Simpson , hackers@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: New scsi_target code References: <35480.1031380829@critter.freebsd.dk> Message-Id: Date: Sat, 07 Sep 2002 07:52:20 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > Scsi-over-IP-over-SCSI-over-firewire? you left out mpls randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 11: 8:58 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF1F537B400 for ; Sat, 7 Sep 2002 11:08:54 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDCBB43E3B for ; Sat, 7 Sep 2002 11:08:53 -0700 (PDT) (envelope-from ticso@cicely9.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.5/8.12.5) with ESMTP id g87I8l6K002071 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 7 Sep 2002 20:08:50 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [IPv6:3ffe:400:8d0:301:210:5aff:fe30:1c1a]) by cicely5.cicely.de (8.12.6/8.12.6) with ESMTP id g87I8kt1003297 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 7 Sep 2002 20:08:46 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (localhost [127.0.0.1]) by cicely9.cicely.de (8.12.6/8.12.5) with ESMTP id g87I8IVk028156; Sat, 7 Sep 2002 20:08:19 +0200 (CEST) (envelope-from ticso@cicely9.cicely.de) Received: (from ticso@localhost) by cicely9.cicely.de (8.12.6/8.12.6/Submit) id g87I8Iog028155; Sat, 7 Sep 2002 20:08:18 +0200 (CEST) Date: Sat, 7 Sep 2002 20:08:18 +0200 From: Bernd Walter To: "Michael R. Wayne" Cc: hackers@FreeBSD.ORG Subject: Re: Excessive swap usage w/ 4.6 Message-ID: <20020907180817.GG26637@cicely9.cicely.de> Reply-To: ticso@cicely.de References: <200209062031.QAA05990@manor.msen.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209062031.QAA05990@manor.msen.com> X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, Sep 06, 2002 at 04:31:18PM -0400, Michael R. Wayne wrote: > > After having moved servers from 4.3 and 4.5 to 4.6, we are noticing > that swap indicates much higher usage. Today, one of our squid > cache servers hit (and stayed at) 50% swap utilization so I decided > to do some digging. > > This machine has 512 MB physical RAM in it and is running > FreeBSD 4.5-RELEASE-p7 > > Here's a ps with some cruft removed and columns widened for readability. > > > ps -axel > CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND > 0 -18 0 0 0 sched DLs ?? 0:00.00 (swapper) > 0 10 0 544 116 wait ILs ?? 0:00.31 /sbin/init -- > 0 -18 0 0 0 psleep DL ?? 5:30.16 (pagedaemon) > 0 18 0 0 0 psleep DL ?? 0:00.04 (vmdaemon) > 0 -18 0 0 0 psleep DL ?? 0:33.61 (bufdaemon) > 0 -2 0 0 0 vlruwt DL ?? 0:29.52 (vnlru) > 0 18 0 0 0 syncer DL ?? 29:36.89 (syncer) > 0 2 0 948 340 select Ss ?? 0:15.27 /usr/sbin/syslogd -s > 0 2 0 1300 352 select Ss ?? 3:52.69 ntpd -p /var/run/ntpd.pid > 0 2 0 1064 560 select Is ?? 0:00.18 /usr/sbin/inetd -wW > 0 10 0 984 216 nanslp Is ?? 0:15.08 /usr/sbin/cron > 28 2 0 2136 264 select Is ?? 3:00.12 /usr/local/sbin/sshd > 0 10 0 2940 0 wait IWs ?? 0:00.00 () /usr/local/sbin/squid > 4 2 0 398380 381916 poll S ?? 286:58.56 (squid) (squid) > 0 -6 0 860 176 piperd Ss ?? 1:35.35 (unlinkd) (unlinkd) > 0 2 0 4792 512 select Ss ?? 0:01.48 sshd: > 0 2 0 2732 1920 select Ss ?? 0:02.73 /usr/local/sbin/gated > 0 2 0 2096 1464 select Ss ?? 0:00.08 /usr/local/sbin/httpd > 0 2 0 2504 1660 accept I ?? 0:00.01 /usr/local/sbin/httpd > 0 2 0 2512 1668 accept I ?? 0:00.01 /usr/local/sbin/httpd > 0 18 0 1584 820 pause Ss p0 0:00.51 SSH_CLIENT= > 0 28 0 416 172 - R+ p0 0:00.00 SSH_CLIENT= > 0 3 0 948 528 ttyin Is+ v0 0:00.00 /usr/libexec/getty Pc ttyv0 > 0 3 0 948 524 ttyin Is+ v1 0:00.00 /usr/libexec/getty Pc ttyv1 > ======= ======= > Totals 427,688 393,208 > -393,208 > ======= > 34,480 So, swap usage should be about this much. But: > > pstat -s > Device 1K-blocks Used Avail Capacity Type > /dev/ad0s1b 614272 304792 309480 50% Interleaved > > This seems very excessive as well as unjustified. Is there some > way I can find out if I have a "swap leak" or some other way to > figure out what is going on? As I mentioned, we noticed a significant > increase in swap usage on many servers between 4.3 or 4.5 and 4.6 If you squid proccess was paged it will keep the swap allocation until the memory is freed. In case pages need to be transfered to swap again it doesn't need to be allocated again - and if the page is unmodified in respect to the swap backed version you even spare the disk access. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 11:41:57 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9175337B400 for ; Sat, 7 Sep 2002 11:41:52 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id CB42D43E3B for ; Sat, 7 Sep 2002 11:41:51 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 10352 invoked by uid 1000); 7 Sep 2002 18:41:52 -0000 Date: Sat, 7 Sep 2002 11:41:52 -0700 (PDT) From: Nate Lawson To: Poul-Henning Kamp Cc: hackers@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: New scsi_target code In-Reply-To: <35902.1031382322@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 7 Sep 2002, Poul-Henning Kamp wrote: > In message , Ju > lian Elischer writes: > > > > > >On Sat, 7 Sep 2002, Poul-Henning Kamp wrote: > >> > >> IP-over-SCSI ? > >> > > > >Well I've just been reading about SCSI over IP.... so > > That's different. IP-over-SCSI is a much wanted Myrinet-light over here. I am not aware of a spec for IP-over-SCSI. Wouldn't it have to use things like AEN to send data in the reverse direction? Of course, the various transports like FC define IP layers but they are usually peers with the SCSI layer. If people are talking about iSCSI, this driver could also support that given that the iSCSI HBA was hooked into the CAM SIM layer. -Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 13:42:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6171A37B400; Sat, 7 Sep 2002 13:42:08 -0700 (PDT) Received: from nelly.internal.irrelevant.org (81-86-164-179.dsl.pipex.com [81.86.164.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 983AB43E6A; Sat, 7 Sep 2002 13:42:01 -0700 (PDT) (envelope-from simond@irrelevant.org) Received: from simond by nelly.internal.irrelevant.org with local (Exim 3.36 #1) id 17nmOd-000Psi-00; Sat, 07 Sep 2002 21:41:35 +0100 Date: Sat, 7 Sep 2002 21:41:35 +0100 From: Simon Dick To: Nate Lawson Cc: Poul-Henning Kamp , hackers@FreeBSD.ORG, scsi@FreeBSD.ORG Subject: Re: New scsi_target code Message-ID: <20020907204135.GB79822@irrelevant.org> References: <35902.1031382322@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Sep 07, 2002 at 11:41:52AM -0700, Nate Lawson wrote: > On Sat, 7 Sep 2002, Poul-Henning Kamp wrote: > > In message , Ju > > lian Elischer writes: > > > > > > > > >On Sat, 7 Sep 2002, Poul-Henning Kamp wrote: > > >> > > >> IP-over-SCSI ? > > >> > > > > > >Well I've just been reading about SCSI over IP.... so > > > > That's different. IP-over-SCSI is a much wanted Myrinet-light over here. > > I am not aware of a spec for IP-over-SCSI. Wouldn't it have to use things > like AEN to send data in the reverse direction? > > Of course, the various transports like FC define IP layers but they are > usually peers with the SCSI layer. > > If people are talking about iSCSI, this driver could also support that > given that the iSCSI HBA was hooked into the CAM SIM layer. Try rfc 2143 :) -- Simon Dick simond@irrelevant.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 19:28:14 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ADAE37B400; Sat, 7 Sep 2002 19:28:11 -0700 (PDT) Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCEDB43E3B; Sat, 7 Sep 2002 19:28:10 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g882S0v29914; Sat, 7 Sep 2002 19:28:00 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Sat, 7 Sep 2002 19:28:00 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Lars Eggert Cc: "Kenneth D. Merry" , Peter Wemm , jlemon@flugsvamp.com, hackers@FreeBSD.ORG, mjacob@FreeBSD.ORG Subject: Re: Ultra320 drivers? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Actually no- they're not, yet. Sorry for the false positive. I also managed to kill your system :-( On Fri, 6 Sep 2002, Matthew Jacob wrote: > > Things are looking a bit better- I have your system at a comfortable > clip with multiple tasks. I'll leave some tests over the weekend, but > I think I nailed it. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Sep 7 23:44:55 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F6F537B400; Sat, 7 Sep 2002 23:44:53 -0700 (PDT) Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3233843E77; Sat, 7 Sep 2002 23:44:52 -0700 (PDT) (envelope-from grog@lemis.com) Received: by wantadilla.lemis.com (Postfix, from userid 1004) id C9053812E3; Sun, 8 Sep 2002 16:14:49 +0930 (CST) Date: Sun, 8 Sep 2002 16:14:49 +0930 From: Greg 'groggy' Lehey To: Stacy Millions Cc: John Baldwin , hackers@FreeBSD.ORG Subject: Re: I climb the mountain seeking wisdom Message-ID: <20020908064449.GG46846@wantadilla.lemis.com> References: <3D78F291.8010005@millions.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D78F291.8010005@millions.ca> User-Agent: Mutt/1.4i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Friday, 6 September 2002 at 12:23:13 -0600, Stacy Millions wrote: > John Baldwin wrote: >> On 06-Sep-2002 Stacy Millions wrote: > >>> At the moment, the whole area of Bus Resources is causing me greif, >>> my panic rate is about 4 or 5 panics/hour (but I'm sure, with some >>> coaching, I could get that to 7 or 8 :-) >> >> What kind of panics? > > > Page fault while in kernel mode.... unfortunately, ddb hangs so I don't > get a core file. That's obviously the first thing you should address. Debugging hasn't changed much since 4.3BSD. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message