Re: install-prompt for missing features (Was: Re: Pull in upstream before 9.1 code freeze?)
On Thursday 05 Jul 2012 13:09:05 per...@pluto.rain.com wrote: Doug Barton do...@freebsd.org wrote: ... something like this would be *really* valuable to ease the transition for people coming from a Linux background. I'm sure some folks here would count this as a reason *not* to provide it :- I think the idea is quite silly all in all - There are 23k Ports a lot of which will have executeables - so everytime I make a typo - a database with - say 30,000-40,000 elements and give me a list back of things I could install from say the russian ports - I don't speak russian. I suggest looking at extending locate(1) or apropos(1) instead. Installed as a default in the shell I would count as a major reason to abandon FreeBSD. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Training wheels for commandline (was Re: Pull in upstream before 9.1 code freeze?)
I am sorry everybody I simply don't get this conversation - Implement it as a port - add it to bash/zsh/tcsh as an option - feel free - But if objective is to make a vanilla FreeBSD easier to use - I can think of 10,000 things (give or take a couple of 1000's) that would be a more wothy target. But for everybody's sake don't pollute the base system - before we know it you would argue that X11/KDE4 should be part of base as well as they make it easier to use. Principle has alway been to try things like that out as ports first and when everybody loves it move it into base (given and take the mandatory wars over copyright types etc). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: MS Vista vs FreeBSD's bootloader
On Thursday 28 June 2007 03:08:34 Garrett Cooper wrote: [EMAIL PROTECTED] wrote: Hi; FWIW, if you just got your new computer with Windows Vista installed and were hoping to dual boot FreeBSD on it, let me tell you that FreeBSD's bootloader will screw things up. Microsoft basically declared the war on alternative OSs so it seems vista doesn't like: - bootloaders different than the one used by Vista. - Making a non Vista partition active. I did what I used to do with XP: I resized the Windows partition with a liveCD and QTparted, Installed FreeBSD with booteasy.. and surprise... Windows Vista won't run again. I then rescued the Vista installation with the install CD (good thing they included that this time, and not only the preinstalled OS!), and looked on the -net for something called EasyBCD, which looks like it will solve the problem by reconfiguring the Vista bootloader. cheers, Pedro. Their excuse is probably to keep (some of the less intelligent) users out there from booting using their own media or alternate means. M$ really must have something important in their bootloader... -Garrett I have Vista Home edition ruinning any FreeBSD without any problems and without having to do anything special - That is on CURRENT ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MS Vista vs FreeBSD's bootloader
On Thursday 28 June 2007 11:33:39 Julian H. Stacey wrote: I have Vista Home edition ruinning any FreeBSD without any problems and without having to do anything special - That is on CURRENT ruinning: No such word ruining: Wrecking, destroying running: Working acceptably - I guess you probably mean this ? LOL - Yes the last - ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MS Vista vs FreeBSD's bootloader
On Thursday 28 June 2007 14:44:05 [EMAIL PROTECTED] wrote: --- Thomas Sparrevohn [EMAIL PROTECTED] ha scritto: ... I have Vista Home edition ruinning any FreeBSD without any problems and without having to do anything special - That is on CURRENT Hmm... Installation order is important, perhaps you already had FreeBSD before installing Vista? In my case Vista Premium came preinstalled, there was also a FAT partition (with diagnostic stuff) and an NTFS for rescue purposes. No - The originally came with XP - I nuked that and installed FreeBSD - However I did nuke the XP totally before upgrading to Vista - It does overwrite the FreeBSD MBR - I just rebooted using a CD and added the mbr again Of course getting the new computer without Vista was not really an option :(, but MS went too far this time, they removed postcript type1 font support and they crippled OpenGL enough that major CAD packages don't work easily or have something like 85% performance penalty. Pedro. ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: DPS Initial Ideas
There is a reason why people have been discussing this for ten years without getting anywhere. I suspect that is because that by and large the ports system works ;-) - Having Played around with a couple of Linux distributions - my impression is that ports offers a much more manageable approach or maybe I am just used to ports ;-) The discussion about ports is really just a subset of the larger discussion about how to get a proper configuration management mechanism - and I am still waiting to see a real good generic answer to that debate - FreeBSD ports offers in min mind a very good candidate or starting point However that being said - there could be benefits to a structured approach to Configuration Identifiers - whether that would result in speed benefits overall - remains to be seen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DPS Initial Ideas
On Monday 14 May 2007 09:25:12 'Michel Talon' wrote: On Mon, May 14, 2007 at 12:33:23AM +0100, Thomas Sparrevohn wrote: converted INDEX into postgresSQL because I was playing around with making a message queue based approach - and it becomes BIG - The only table structure difference from the current format was that I was able to track who is depending on a port - which I am pretty sure could be handled in the current framework - e.g. we could add a file having the depending port names or so niobe% cp /usr/ports/INDEX-6 . niobe% sqlite3 index.db sqlite CREATE TABLE index6 ( pkgname varchar(1), path varchar(1), prefix varchar(1), comment varchar(1), descr varchar(1), maintainer varchar(1), categories varchar(1), build_deps varchar(1), run_deps varchar(1), website varchar(1), extract_deps varchar(1), patch_deps varchar(1), fetch_deps varchar(1)); sqlite .import INDEX-6 index6 ... completes in less than 2 seconds sqlite select * from index6 where path = /usr/ports/accessibility/atk; atk-1.12.4|/usr/ports/accessibility/atk|/usr/local|A GNOME accessibility toolkit (ATK)|/usr/ports/accessibility/atk/pkg-descr|[EMAIL PROTECTED]|accessibility devel|gettext-0.14.5_2 glib-2.12.9 libiconv-1.9.2_2 libtool-1.5.22_3 perl-5.8.8 pkg-config-0.21|gettext-0.14.5_2 glib-2.12.9 libiconv-1.9.2_2 perl-5.8.8 pkg-config-0.21|http://developer.gnome.org/projects/gap/||libtool-1.5.22_3| niobe% ls -lh INDEX-6 index.db -rw-r--r-- 1 michel lpthe 9,5M 14 mai 10:00 INDEX-6 -rw-r--r-- 1 michel lpthe12M 14 mai 10:12 index.db Where is this huge increase in size? Admittedly, i have not created indexes, etc. Compare this to the portsdb created by portupgrade from the same INDEX-6 niobe% ls -lh /usr/ports/INDEX-6.db -rw-r--r-- 1 root wheel21M 16 fév 13:36 /usr/ports/INDEX-6.db Surprise, surprise, the BerkeleyDB suddenly appears less glorious. That you table structure does not even full fill 1st normal form ;-) - You need to convert that into independent tables in order to get it on a reasonable normal form format ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DPS Initial Ideas
On Sunday 13 May 2007 11:37:57 Peter Jeremy wrote: The options I can see are: - Ignore the existence of INDEX - which makes computing dependencies very time consuming - Fully rebuild INDEX via make describe whenever you update any ports - this takes of the order of an hour - Find and rebuild the changed bits of INDEX - p5-FreeBSD-Portindex uses this approach. - Build a tool that functionally does make describe but does it in bulk much faster (eg by pre-parsing the include files once instead of 17000 times). Having played around with using Postgres as a database for ports - I must stress that its not a database vs. flatfile issue - It is quite easy to build a reasonable Ports database - however it does not help on the issue - namely that dependencies and options means that it is needed to run make in order to gurantee that the INDEX file are correct It seems to be a non-debate what format the database is in if there not a good answer to how ensure that only ports that has changed are updated. At the end of the day - make based ports are the only real safe way to manage ports - However the focus on the indexing side seems misplaced - example - make INDEX on this host take 8-12 Minutes - compiling all ports installed takes 24 Hours - now if I hand build the dependencies structure and run the builds in parallel it takes down to 4-5 Hours - so lets say we half the time it takes to maintain the index - well - it cuts minimum time off the entire build process and the effort and energy proberly better spend on trying to define a build sequence that allows ports to build with make -j x and with parallel builds where -j n does not work Using XML for INDEX are a very good idea mainly because it allows ports to interface in an easy way to external tools - e.g. java frontends - web browsers etc, etc. However there are drawbacks - Yet I feel that the discussion about what tool to use as indexing are completely misplaced if the only point is that somebody likes SQL better than a directory tree. Yes, and i don't buy the idea that using *existing* tools is better than using the best tool for the job (assuming one can prove what is the best tool, considering power, familiarity, etc.). Remind me - we are told that SQL are the answer but what was the question again? Demonstrate a better tool. Always the best way ;-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: DPS Initial Ideas
Well - Naturally if the only index format was based upon XML it would not be very practical - However XML currently seems to take the lead when the talk is on portability as a data format and it is very easy to convert to Pure Text - There seems to be a bias towards SNMP MIB format generally in FreeBSD e.g. sysctl etc. which has even worse drawbacks But as I said - I very much doubt that the format of the INDEX file and the on disk package db structure is the most burning issue for ports - I am sure that there are optimisations that could improve the current performance without having to change the structure into SQL - If however that is the target then XML would be a significantly better candidate because a proper XML schema can be used as a middle layer for all the tools - regardless the storage structure of the package db etc. - If we introduced a proper abstraction - then people can use SQL/ flat files / existing structures But the tools we still only need one common interface to XML -Original Message- From: Benjamin Lutz [mailto:[EMAIL PROTECTED] Sent: 13 May 2007 19:42 To: freebsd-hackers@freebsd.org Cc: Thomas Sparrevohn; Michel Talon Subject: Re: DPS Initial Ideas On Sunday 13 May 2007 13:58, Thomas Sparrevohn wrote: Using XML for INDEX are a very good idea mainly because it allows ports to interface in an easy way to external tools - e.g. java frontends - web browsers etc, etc. However there are drawbacks - Yet I feel that the discussion about what tool to use as indexing are completely misplaced if the only point is that somebody likes SQL better than a directory tree. I'd have said that using XML for INDEX is a bad idea, because INDEX can then no longer be easily processed with any of the tools in the FreeBSD base system. With the format it uses now, I can easily grep, awk, etc it. If you need an XML version of INDEX, it's easy to have just these tools build one for you though. Not to mention that INDEX is already big enough as it is, imo. I don't see why it should be bloated even more with redundant information. Cheers Benjamin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: DPS Initial Ideas
FYI, Using XML and other buzzword-compliance is not currently on the table either. Let's all try to maintain some focus, OK? Well - I now heard the SQL buzzword quite a bit ;-) - but whatever - No matter what angle I take on the register/make INDEX timing issues they are insignificant compared to potential gains in the single vs. Parallel builds scenario - even with my UP system - a total rebuild of the ports I had installed took way 24 hours of which the time used in register etc was and are only a fraction In my view ports should be self contained within the FreeBSD system - Focusing on The on-disk format seems to be the wrong angle on the issue - The current structure Works well - but it has a number of drawbacks - however it no way clear whether that The answer is another INDEX/storage structure ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: DPS Initial Ideas
On Sunday 13 May 2007 23:00, Thomas Sparrevohn wrote: The on-disk format seems to be the wrong angle on the issue - The current structure Works well - but it has a number of drawbacks - however it no way clear whether that The answer is another INDEX/storage structure When coming up with ideas what to change INDEX's storage method to, just keep in mind that - There is very little flexibility whatsoever in the way data is stored in the file. Each entry in the INDEX has its 13 or so fields, and that's it. One of the strengths of XML, self-descriptiveness for very dynamic data structures, doesn't matter for INDEX. Basically, imho, using XML for tabular data = bad. Agree and Disagree ;-) For an on disk storage structure absolutely yes - A file that was native XML does not make sense - let's forget XML/SQL etc For a second The issue at hand is two/many fold - What I am trying to convey is 1) There is one discussion about Internal Ports and FreeBSD on disk format 2) There is one discussion about what are the best ABI for tools using that data 3) There is a discussion about Dependency handling in general The issue of looking up an installed port can be handled separately - and indeed most Of the port management tools does exactly that e.g. portupgrade The challenge with ports are the static dependencies and the ad-hoc dependencies. - INDEX exists for speed. Accessing the information in it should be as fast as possible. I object to any change that increases the time needed to search for and parse INDEX entries. I've written a little searching tool (it can be found ports-mgmt/psearch). If INDEX were to be converted to XML, just because of that it would be considerably slower. If psearch then were to use standard XML parsing libs, the slowdown would probably be at least an order of magnitude. Absolutely - that is exactly the problem - all the port maintenance tools are Depending on a intimate understanding of directory structures etc making it Very tricky to change without breaking the tools. The second point is most important here. This whole thread exists because people consider the existing ports system to be too slow. How is using XML going to help with that at all? But exactly what is to slow? - The fact that be default the system is single threaded or make install. IMO Ports are still far better that most other approaches- I converted INDEX into postgresSQL because I was playing around with making a message queue based approach - and it becomes BIG - The only table structure difference from the current format was that I was able to track who is depending on a port - which I am pretty sure could be handled in the current framework - e.g. we could add a file having the depending port names or so I would think a better approach would be to use a static matrix or an information tree structure. In another life I solved a problem like this that way e.g. each entry was assigned a unique prefix sequence etc. I am not sure however if that would be overkill for a typical install base of 500-600 ports. I suggest that people play around with INDEX and SQL - it quite easy to make a schema and a data loader - On a day to day basis I doubt that it will be much faster because it has to scan the ports directory as well. Regards T. PS. Another fun thing to play with is to load all files into a database - Makefile the lot ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: DPS Initial Ideas
You got it -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of Duane Whitty Sent: 13 May 2007 22:21 To: Kris Kennaway Cc: freebsd-hackers@freebsd.org; [EMAIL PROTECTED] Subject: Re: DPS Initial Ideas On Sunday, 13 May 2007 at 17:04:20 -0400, Kris Kennaway wrote: On Sun, May 13, 2007 at 10:00:46PM +0100, Thomas Sparrevohn wrote: The answer is another INDEX/storage structure Great, I look forward to your detailed proposal. Kris I believe this is closer to what Thomas meant: but it has a number of drawbacks - however it [is in] no way clear whether the answer is another INDEX/storage structure Correct me if I am wrong Thomas. Duane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: DPS Initial Ideas
The second point is most important here. This whole thread exists because people consider the existing ports system to be too slow. How is using XML going to help with that at all? But which part? The /var half of the equation - well that depends on the operation - Lookup? E.g. testing for the existence of another port? Update? E.g. Updating a dependency (Implicit Lookup) Delete? E.g. Removing (Implicit Update and Lookup) Install and so on Lookup and update can be optimized but for what install base? E.g. Do we know how many ports the typical system has? A simple solution - to the lookup and update - could be to have a master dependencies matrix N x N where each dimension is a port and a dependency - if the typical install base is say 500 ports that only has to be 500x500 bits - and so on. The /usr/ports/INDEX side is another issue totally - and the primary problem is maintaining the file without having to visit all directories - well - a simple hack is only to update changed records based upon mtime - it's still nasty - because all dependencies has to be changed as well. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: NVIDIA FreeBSD kernel feature requests
That is puzzling - I running using on a Nvidia Nforce 590 SLI based machine with no problems using Raid - Mind you this Dell implementation uses only Raid0 - What release are you running? - I have had success With both 6.2, 7.0-Current and AMD-6.2 and AMD-7.0 - On the 64bit there was issues with the USB - which has been and there was some issues with SATA CD drives all of which is fixed -Original Message- From: [EMAIL PROTECTED] [mailto:owner-freebsd- [EMAIL PROTECTED] On Behalf Of MOUILLE Jean Pierre Ext OF/DT Sent: 29 March 2007 10:55 To: freebsd-hackers@freebsd.org Subject: NVIDIA FreeBSD kernel feature requests Hello, Do you plan for a driver for nForce 590sli RAID controller on FreeBSD ? The disks are recognized but not the RAID arrays. On Motherboard ECS KN3-SLI2, JMicron JMB363 driver is already included in FreeBSD 6.2 (ar0) but in kernel, it goes up to nForce 4. Perhaps have you got later information ? Jean-Pierre Mouillé ORANGE-FRANCE/DT/DPP/SC 01.55.22.27.57 [EMAIL PROTECTED] P please consider the environment - do you really need to print this email? * This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers- [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Weird behaviours with SATA DVD Drives
Hi I just got a new system that has two SATA DVD Drives in it. There are a couple of weird issues so I list in order - With the Jan snapshot the kernel only see the DVD Drive that the CD was booted in - but it cannot later on when sysinstall is running use the drive but gives read errors So I installed the system from a spare USB CD Drive - When I boot the system normally it does not find any SATA DVD's at all - atacontrol comes out blank - However if I boot from a DVD drive with unload Rootdev=disk0s1 Currdev=disk0s1 The atacontrol can see the opposite drive to the one I booted from. So I CVSUP'ed and got the kernel up to date and here what happens I am still booting from the DVD Drive but running the systems of the internal disk and here the funny thing. The kernel can see one drive - However if I detach that CD and detach the empty SATA channel where the other CD are I can attach any one of them - but not at the same time See the atacontrol for the sequence - I can make the kernel panic - if I have one drive attached and detach the other channel and try to reinit it the kernel panics with a mutex error in ata-queue - unfortunately I done have a kernel dump Regards Thomas ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ancient FreeBSD releases online
On Sunday 03 July 2005 10:05, Poul-Henning Kamp wrote: Fedt - Jeg tror at jeg stadigvaek har nogle of de originale CD'er - ftp://phk.freebsd.dk ./386BSD/cd1.iso ./BSD4.4-LITE/cover.pnm ./BSD4.4-LITE/cd1.iso ./BSD4.4-LITE/cd2.iso ./BSD4.4-LITE/cd3.iso ./FreeBSD-1.0-RELEASE/cover.pnm ./FreeBSD-1.0-RELEASE/cd1.iso ./FreeBSD-1.1-RELEASE/cd1.iso ./FreeBSD-1.1.5.1/cd1.iso ./FreeBSD-2.0-RELEASE/cd1.iso ./FreeBSD-2.0-RELEASE/cover_black.pnm ./FreeBSD-2.0-RELEASE/cover_green.pnm ./FreeBSD-2.0.5-RELEASE/cover.pnm ./FreeBSD-2.0.5-RELEASE/cd1.iso ./FreeBSD-2.0.5-RELEASE/cd2.iso ./FreeBSD-2.1-RELEASE/cd1.iso Still in upload queue: ./FreeBSD-2.1-RELEASE/cd2.iso ./FreeBSD-2.1.5-RELEASE/cd1.iso ./FreeBSD-2.1.5-RELEASE/cd2.iso ./FreeBSD-2.1.6-RELEASE/cd1.iso ./FreeBSD-2.1.6-RELEASE/cd2.iso ./FreeBSD-2.1.7-RELEASE/cd1.iso ./FreeBSD-2.1.7-RELEASE/cd2.iso ./FreeBSD-2.2-960501-SNAP/cd1.iso ./FreeBSD-2.2-960801-SNAP/cd1.iso ./FreeBSD-2.2-961014-SNAP/cd1.iso ./FreeBSD-2.2.1-RELEASE/cd1.iso ./FreeBSD-2.2.1-RELEASE/cd2.iso ./FreeBSD-2.2.2-RELEASE/cd1.iso ./FreeBSD-2.2.2-RELEASE/cd2.iso ./FreeBSD-2.2.5-RELEASE/cd1.iso ./FreeBSD-2.2.5-RELEASE/cd2.iso ./FreeBSD-2.2.5-RELEASE/cd3.iso ./FreeBSD-2.2.5-RELEASE/cd4.iso The server is a Soekris NET4801 and it's primary task is my email, so if this gets abused it'll disappear again. Mirrors welcome. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Debugging UMA allocation
Hi
One of the changes introduced after the 27/05 causes a panic in the initial
boot phases in the
The panic occurs on my Dell Lattitude C640 when using both my own kernel and
the GENERIC kernel.
The panic is
_mtx_lock_sleep: Recursed on non-recursive mutex in system map
I have traced the trigger panic to the first call to uma_zcreate in procinit
called from proc0_init - I have just cvs-supped again but the error is still
there
Unfortunately because it happend before anything is up and running I have no
way of producing a kernel dump and as the problem does not seem to be widely
reported I assume it is specific to this Dell Laptop type
The dmesg included are provided as reference only for the last good
compilation of the that I know off e.g. the kernel I know that boots - I have
been trying for about 2-3 days which should narrow down the time
Can anybody give any advise on how to progress?
/*
RSD PTR: OEM=DELL, ACPI_Rev=1.0x (0)
RSDT=0x000fde64, cksum=47
*/
/*
RSDT: Length=40, Revision=1, Checksum=165,
OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d4010c,
Creator ID=ASL, Creator Revision=0x61
Entries={ 0x000fde90 }
*/
/*
FACP: Length=116, Revision=1, Checksum=188,
OEMID=DELL, OEM Table ID=CPi R, OEM Revision=0x27d4010c,
Creator ID=ASL, Creator Revision=0x61
FACS=0x3800, DSDT=0xfffe4000
INT_MODEL=PIC
Preferred_PM_Profile=Unspecified (0)
SCI_INT=9
SMI_CMD=0xb2, ACPI_ENABLE=0x70, ACPI_DISABLE=0x71, S4BIOS_REQ=0x97
PSTATE_CNT=0x80
PM1a_EVT_BLK=0x800-0x803
PM1a_CNT_BLK=0x804-0x805
PM2_CNT_BLK=0x820-0x820
PM_TMR_BLK=0x808-0x80b
GPE0_BLK=0x828-0x82b
GPE1_BLK=0x82c-0x82f, GPE1_BASE=16
P_LVL2_LAT=50 us, P_LVL3_LAT=2000 us
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=1, DUTY_WIDTH=3
DAY_ALRM=0, MON_ALRM=0, CENTURY=0
IAPC_BOOT_ARCH=
Flags={WBINVD,PROC_C1,PWR_BUTTON,SLP_BUTTON,DCK_CAP}
*/
/*
FACS: Length=64, HwSig=0x00ff, Firm_Wake_Vec=0x
Global_Lock=
Flags=S4BIOS
Version=0
*/
/*
DSDT: Length=12700, Revision=1, Checksum=38,
OEMID=INT430, OEM Table ID=SYSFexxx, OEM Revision=0x1001,
Creator ID=MSFT, Creator Revision=0x10e
*/
0 255 N 0 9 10 11
pci_link1: ACPI PCI Link LNKB irq 11 on acpi0
pci_link1: Links after initial probe:
Index IRQ Rtd Ref IRQs
0 11 N 0 5 7
pci_link1: Links after initial validation:
Index IRQ Rtd Ref IRQs
0 255 N 0 5 7
pci_link1: Links after disable:
Index IRQ Rtd Ref IRQs
0 255 N 0 5 7
pci_link2: ACPI PCI Link LNKC irq 11 on acpi0
pci_link2: Links after initial probe:
Index IRQ Rtd Ref IRQs
0 11 N 0 9 10 11
pci_link2: Links after initial validation:
Index IRQ Rtd Ref IRQs
0 11 N 0 9 10 11
pci_link2: Links after disable:
Index IRQ Rtd Ref IRQs
0 255 N 0 9 10 11
pci_link3: ACPI PCI Link LNKD irq 11 on acpi0
pci_link3: Links after initial probe:
Index IRQ Rtd Ref IRQs
0 11 N 0 5 7 9 10 11
pci_link3: Links after initial validation:
Index IRQ Rtd Ref IRQs
0 11 N 0 5 7 9 10 11
pci_link3: Links after disable:
Index IRQ Rtd Ref IRQs
0 255 N 0 5 7 9 10 11
ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 - 10
Timecounter ACPI-fast frequency 3579545 Hz quality 1000
acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
cpu0: ACPI CPU port 0x530-0x537 on acpi0
acpi_perf0: ACPI CPU Frequency Control on cpu0
acpi_throttle0: ACPI CPU Throttling on cpu0
acpi_throttle0: P_CNT from P_BLK 0x8e0
acpi_acad0: AC Adapter on acpi0
acpi_cmbat0: Control Method Battery on acpi0
acpi_cmbat1: Control Method Battery on acpi0
acpi_lid0: Control Method Lid Switch on acpi0
acpi_button0: Power Button on acpi0
acpi_button1: Sleep Button on acpi0
pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0
pci0: ACPI PCI bus on pcib0
pci0: physical bus=0
found- vendor=0x8086, dev=0x1a30, revid=0x04
bus=0, slot=0, func=0
class=06-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
map[10]: type 3, range 32, base e800, size 26, enabled
found- vendor=0x8086, dev=0x1a31, revid=0x04
bus=0, slot=1, func=0
class=06-04-00, hdrtype=0x01, mfdev=0
cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords)
lattimer=0x20 (960 ns), mingnt=0x0e (3500 ns), maxlat=0x00 (0 ns)
found- vendor=0x8086, dev=0x2482, revid=0x02
bus=0, slot=29, func=0
class=0c-03-00, hdrtype=0x00, mfdev=1
cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=11
map[20]: type 4,
Re: Debugging UMA allocation
On Sunday 05 June 2005 12:31, Thomas Sparrevohn wrote: Ups - two useless files included - please ignore the plugins.txt and the dmesg - it should have been Hi One of the changes introduced after the 27/05 causes a panic in the initial boot phases in the The panic occurs on my Dell Lattitude C640 when using both my own kernel and the GENERIC kernel. The panic is _mtx_lock_sleep: Recursed on non-recursive mutex in system map I have traced the trigger panic to the first call to uma_zcreate in procinit called from proc0_init - I have just cvs-supped again but the error is still there Unfortunately because it happend before anything is up and running I have no way of producing a kernel dump and as the problem does not seem to be widely reported I assume it is specific to this Dell Laptop type The dmesg included are provided as reference only for the last good compilation of the that I know off e.g. the kernel I know that boots - I have been trying for about 2-3 days which should narrow down the time Can anybody give any advise on how to progress? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Debugging UMA allocation
On Sunday 05 June 2005 13:17, Thomas Sparrevohn wrote: Ok - After a hand held trace - here are what happens In the call to uma_zcreate for the PROC object the slab_zalloc ends up being called twice - it in turn calls vm_map_lock and establishes the first time a exclusive sleep mutex on the region 0xc1059144 through a call to vm_map_lock in the startup_alloc - however that lock are nover released so when the second call to slab_zalloc is executed it in turns again calls startup_alloc which in turn again calls page_alloc-kmem_malloc-vm_map_lock with the same region which by now holds an exclusive lock that the first call established and the kernel panics Could it be because the booted vairable holds the value 1 or it that a long shot? On Sunday 05 June 2005 12:31, Thomas Sparrevohn wrote: Ups - two useless files included - please ignore the plugins.txt and the dmesg - it should have been Hi One of the changes introduced after the 27/05 causes a panic in the initial boot phases in the The panic occurs on my Dell Lattitude C640 when using both my own kernel and the GENERIC kernel. The panic is _mtx_lock_sleep: Recursed on non-recursive mutex in system map I have traced the trigger panic to the first call to uma_zcreate in procinit called from proc0_init - I have just cvs-supped again but the error is still there Unfortunately because it happend before anything is up and running I have no way of producing a kernel dump and as the problem does not seem to be widely reported I assume it is specific to this Dell Laptop type The dmesg included are provided as reference only for the last good compilation of the that I know off e.g. the kernel I know that boots - I have been trying for about 2-3 days which should narrow down the time Can anybody give any advise on how to progress? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mergemaster improvement (auto-update for not modified files)
On Wednesday 04 May 2005 06:38, M. Warner Losh wrote: The technical reasons are very simple. If a new system call is created, and programs use that new system call, then if you do an installworld before you boot the kernel, that can result in binaries not working. This has happened with important ones like /bin/sh in the past. In addition, if you aren't running single user, many different races exist in the installation process that can result in bad behavior. There are also potential problems with symbols in there's a large jump between the revisions being updated. Usually you can get away with it, but if you want to be safe, you must do the install in single user. Usually, however, has lead in the past to problems, which is why the project recommendations are conservative. A auto-scripted install directly run from rc.d in single-user mode would cover both requirements - I seem to recall that Solaris had something like it at a point. Somewhat along the lines of nextboot would be nice. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: backporting GEOM to the 4.x branch
On Monday 28 February 2005 00:15, Maxim Sobolev wrote: Roland Dowdeswell wrote: [ cc'ing [EMAIL PROTECTED], because there has been talk of GBDE there in the past.] So what? If the write fails in the middle, reading sector will just produce garbage. I don't think that it's different from plain old HDD which has been powered down in the middle of doing disk write. Disk encryption layer is definitely not the level at which journaling should be implemented. It's task of file system to do this. The task of encryption layer is merely to inform the file system when transaction (i.e. both of those two writes in this case) have been completed successfully, so that FS can adjust its journal accordingly. -Maxim I could be wrong but I would assume that if it is correctly handled within softupdates there should be no need for journalling - e.g. If both transactions are not completed the writes are ignored ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Wednesday 06 October 2004 02:31, Matthew Dillon wrote: The university I used to work for had something like it and it got 99% of the cases Yow. 78 messages and counting. Er, 79 now. I'll bet poor Giorgos wishes he never started this thread! Get ready. get set DIVE! A good friend of mine has, for at least the last two decades, used something along the lines of: if ( $?prompt ) then alias rm 'mv \!* $HOME/misc/trash' endif However, it seems that the correct solution is to create a new option, -I, which puts rm into 'idiot user mode' and has all the desired confirmation effects listed in this thread and none of the undesired effects such as -i returns. Then if anyone wants to use it they can just create an alias similar to the above for -I and poof, problem solved. It's fairly easy to detect '*' and ask for confirmation, and also easy to ask for a single confirmation on a directory (not ask again for any recursion). Then you guys can argue over whether the alias should appear in the system-wide default csh.cshrc and friends, rather then argue over the destruction of rm's basic nature. I will only point out that 'rm' is used fairly universally in scripts and there are obviously things other then '/' that you would want to ask confirmation for that just as obviously cannot be made default operation for rm. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
A simple and pragmatic solution is to use alias in what ever shell you are using e.g. alias rm to rm -i. There used to be a simple delete command or script that basically moved all files into a .deleted directory insted of actually deleting the files - From a practical point of view it does the trick because it forces anybody to use the escaped version if they really want to delete the files. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
