Re: ar(1) format_decimal failure is fatal?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/18/10 03:24, Tim Kientzle wrote:
>
> On Sep 17, 2010, at 9:01 PM, Benjamin Kaduk wrote:
>
>> On Sun, 29 Aug 2010, Jilles Tjoelker wrote:
>>
>>> On Sat, Aug 28, 2010 at 07:08:34PM -0400, Benjamin Kaduk wrote:
[...]
building static egacy library
ar: fatal: Numeric user ID too large
*** Error code 70
>>>
This error appears to be coming from
lib/libarchive/archive_write_set_format_ar.c , which seems to only have
provisions for outputting a user ID in AR_uid_size = 6 columns.
>> [...]
It looks like this macro was so defined in version 1.1 of that file, with
commit message "'ar' format support for libarchive, contributed by Kai
Wang.". This doesn't make it terribly clear whether the 'ar' format
mandates this length, or if it is an implementation decision...
>
> There's no official standard for the ar format, only old
> conventions and compatibility with legacy implementations.
>
>>> I wonder if the uid/gid fields are useful at all for ar archives. Ar
>>> archives are usually not extracted, and when they are, the current
>>> user's values seem good enough. The uid/gid also prevent exactly
>>> reproducible builds (together with the timestamp).
>>
>> GNU binutils has recently (well, March 2009) added a -D ("deterministic")
>> argument to ar(1) which sets the timestamp, uid, and gid to zero, and the
>> mode to 644. If that argument is not given, linux's ar(1) happily uses my
>> 8-digit uid as-is; the manual page seems to imply that it will handle 15 or
>> 16 digits in that field.
>
> Please send me a small example file... I don't think I've seen
> this format variant. Maybe we can extend our ar(1) to support
> this variant.
>
> Personally, I wonder if it wouldn't make sense to just always
> force the timestamp, uid, and gid to zero. I find it hard
> to believe anyone is using ar(1) as a general-purpose archiving
> tool. Of course, it should be trivial to add -D support to our ar(1).
>
>> I propose that format_{decimal,octal}() return ARCHIVE_FAILED for negative
>> input, and ARCHIVE_WARN for overflow. archive_write_ar_header() can then
>> catch ARCHIVE_WARN from the format_foo functions and continue on,
>> propagating the ARCHIVE_WARN return value at the end of its execution ...
>
> This sounds entirely reasonable to me. I personally don't see much
> advantage to distinguishing negative versus overflow, but certainly
> have no objections to that part. Definitely ar(1) should not abort on
> a simple ARCHIVE_WARN.
>
>> Would (one of) you be willing to review a patch to that effect?
>
> Happy to do so.
>
Hi,
I've been using the attached patch for quite some time now. It basically
replace the offending gid/uid with nobody's id when necessary.
If I remember correctly, Tim was supposed to add them to the upstream version of
libarchive and then import them back in fbsd. Tim, do you remember what
happened with those?
Regards,
Steph
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyZI38ACgkQmdOXtTCX/nt2WwCgqvd4GIyE5zRvL5kkHCWTGoAA
yA0AoJ/8Dx2QrLXAJHkOrd1YqW+QR03h
=KxCW
-END PGP SIGNATURE-
Index: usr.bin/tar/write.c
===
--- usr.bin/tar/write.c (revision 212556)
+++ usr.bin/tar/write.c (working copy)
@@ -439,7 +439,30 @@
{
const char *arg;
struct archive_entry *entry, *sparse_entry;
+ struct passwdnobody_pw, *nobody_ppw;
+ struct group nobody_gr, *nobody_pgr;
+ char id_buffer[128];
+ /*
+* Some formats (like ustar) have a limit on the size of the uids/gids
+* supported. Tell libarchive to use the uid/gid of nobody in this case
+* instead of failing.
+*/
+ getpwnam_r("nobody", &nobody_pw, id_buffer, sizeof (id_buffer),
+ &nobody_ppw);
+ if (nobody_ppw)
+ archive_write_set_nobody_uid(a, nobody_ppw->pw_uid);
+ else
+ bsdtar_warnc(0,
+ "nobody's uid not found, large uids won't be supported.");
+ getgrnam_r("nobody", &nobody_gr, id_buffer, sizeof (id_buffer),
+ &nobody_pgr);
+ if (nobody_pgr)
+ archive_write_set_nobody_gid(a, nobody_pgr->gr_gid);
+ else
+ bsdtar_warnc(0,
+ "nobody's gid not found, large gids won't be supported.");
+
/* Allocate a buffer for file data. */
if ((bsdtar->buff = malloc(FILEDATABUFLEN)) == NULL)
bsdtar_errc(1, 0, "cannot allocate memory");
Index: usr.bin/tar/bsdtar.1
===
--- usr.bin/tar/bsdtar.1(revision 212556)
+++ usr.bin/tar/bsdtar.1(working copy)
@@ -1027,3 +1027,6 @@
convention can cause hard link information to be lost.
(Th
Re: telnetd[20170]: ttloop: peer died: Resource temporarily unavailable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
vasanth raonaik wrote:
> Hello Hackers,
>
> I am seeing this message continuously in syslog for every 60 secs. what
> could be the possible reasons for this error messages.
Are you using an amd64 kernel? If so, you could try the attached patch.
I've encountered a similar problem today (in my case the problem was
with dbus) where select would fail due to a 64->32 bit truncation in the
kernel.
Steph
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmF7mAACgkQmdOXtTCX/ntNWACeJ9TYzbl9hW5aheJP/RtLm2J0
/aMAoIUHbBpsD1v6O30yXpuXkRZWaEfN
=4JD4
-END PGP SIGNATURE-
Index: kern/sys_generic.c
===
--- kern/sys_generic.c (revision 187983)
+++ kern/sys_generic.c (working copy)
@@ -903,7 +903,7 @@
* bit position in the fd_mask array.
*/
static __inline int
-selflags(fd_mask **ibits, int idx, int bit)
+selflags(fd_mask **ibits, int idx, fd_mask bit)
{
int flags;
int msk;
@@ -912,7 +912,7 @@
for (msk = 0; msk < 3; msk++) {
if (ibits[msk] == NULL)
continue;
- if ((ibits[msk][idx] & (fd_mask)bit) == 0)
+ if ((ibits[msk][idx] & bit) == 0)
continue;
flags |= select_flags[msk];
}
lp64_select_fix.diff.sig
Description: Binary data
___
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: PCI Express graphics reliability/functionality in 6.1?
Clifton Royston wrote: > I'm soon to build myself a new AMD X2 workstation system on which I > plan to multiboot various operating systems including FreeBSD, a couple > Linux distros and probably Windows XP Pro, and probably also run > virtualization software (VMWare and/or Xen.) I'm hoping for it to last > me through a few years of occasional upgrades, which makes me dubious > about choosing an AGP motherboard. > > I can't find anything specific about PCI Express in the 6.1 release > notes. However, I have Googled up some reports of various PCI-E > graphic cards working badly in Xorg under FreeBSD and other open source > OSes. In general should PCI Express graphics cards work properly and > perform reasonably well for Xorg and OpenGL graphics under FreeBSD, if > I avoid the "touchier" nVidia cards, or do I need to stick with AGP for > reliability? > > If there's a better mailing list for getting an authoritative answer > to this, I'd appreciate the pointer. I have an nVidia GeForce Go 7800 connected on a PCI Express 16X bus which is working very well under Xorg with FreeBSD Current and the nvidia driver from ports. It's connected to a 945PM chipset from Intel. So far it's been very stable and it's been giving me very good performances with UT2004 and Quake3. The only time I've got crashes what when I tried to use one of the raster modes on the syscon console. The system would crash trying to map the syscon framebuffer when I switched to any vt. Steph ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ARM Port: Help with UMA subsystem needed
On Sat, Aug 03, 2002 at 03:51:20PM -0400, Jeff Roberson wrote:
>
> On Sat, 3 Aug 2002, Bosko Milekic wrote:
>
> >
> > On Sat, Aug 03, 2002 at 11:07:11AM -0400, Stephane E. Potvin wrote:
> > >
> > > I just found out that reverting this commit fixes the problem. Any
> > > ideas about why other arches don't encouter the problem?
> > >
> > > jeff2002/06/19 13:49:44 PDT
> > >
> > > Modified files:
> > > sys/vm uma.h uma_core.c
> > > Log:
> > > - Remove bogus use of kmem_alloc that was inherited from the old zone
> > > allocator.
> >
> >This looks like the problem, or at least that which uncovers the
> >problem. The pmap code is calling the zone allocator as well and
> >what happens is that you recurse on the kmem_map lockmgr lock because
> >you allocate recursively from kmem_map. Previously, we could also
> >allocate from kernel_map, if the kernel_map lockmgr lock wasn't held,
> >so this way if we had a recursive call we would get around this
> >problem. I think this whole thing is flaky in general (if this was
> >the way to get around recursion, we should fix it).
> >
> >JHB and/or JeffR: why is the kmem_map lockmgr lock not recursive?
> >
>
> These locks can not be made recurisve safely. In this case you would just
> recurse forever and never satisfy the allocation. All pmap modules do
> something like the following:
>
> static void *
> pmap_allocf(uma_zone_t zone, int bytes, u_int8_t *flags, int wait)
> {
> *flags = UMA_SLAB_PRIV;
> return (void *)kmem_alloc(kernel_map, bytes);
> }
>
> pvzone = uma_zcreate("PV ENTRY", sizeof (struct pv_entry), NULL,
> NULL,
> NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_VM);
> uma_zone_set_allocf(pvzone, pmap_allocf);
> uma_prealloc(pvzone, initial_pvs);
>
>
> Is arm using a seperate allocf?
Ok, you'll have to pass me a pointy hat. When I brought back my code back
in sync with current it seems that I overlooked that the pv entries needs
to be allocated with a UMA_ZONE_VM flag. With this I'm now able to boot
up to cpu_thread_setup (which I still need to implement).
Thanks again and sorry for the false alarm
Steph
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ARM Port: Help with UMA subsystem needed
On Thu, Aug 01, 2002 at 08:05:12PM -0400, Stephane E. Potvin wrote: > I've been busy trying to bring the port back in sync with current. > Now, each time I start my NetWinder, I get the following panic which > I don't seem able to track the source. I would greatly appreciate if > anybody knowledgeable with the UMA subsystem could give me a hint on > what could be causing this. > I just found out that reverting this commit fixes the problem. Any ideas about why other arches don't encouter the problem? jeff2002/06/19 13:49:44 PDT Modified files: sys/vm uma.h uma_core.c Log: - Remove bogus use of kmem_alloc that was inherited from the old zone allocator. - Properly set M_ZERO when talking to the back end page allocators for non malloc zones. This forces us to zero fill pages when they are first brought into a cache. - Properly handle M_ZERO in uma_zalloc_internal. This fixes a problem where per cpu buckets weren't always getting zeroed. Revision ChangesPath 1.9 +0 -1 src/sys/vm/uma.h 1.30 +18 -16src/sys/vm/uma_core.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ARM Port: Help with UMA subsystem needed
I've been busy trying to bring the port back in sync with current.
Now, each time I start my NetWinder, I get the following panic which
I don't seem able to track the source. I would greatly appreciate if
anybody knowledgeable with the UMA subsystem could give me a hint on
what could be causing this.
Panic information:
kmeminit: mem_size = 003d
kmeminit: vm_kmem_size = 007a
kmeminit: npg = 0f24
Allocating one item from KMAP ENTRY(0xc0675640)
uma_zalloc_arg: Bucketzone returned NULL
INTERNAL: Allocating one item from KMAP ENTRY(0xc0675640)
Allocating one item from MAP(0xc0675500)
uma_zalloc_arg: Bucketzone returned NULL
INTERNAL: Allocating one item from MAP(0xc0675500)
Allocating one item from KMAP ENTRY(0xc0675640)
uma_zalloc_arg: Bucketzone returned NULL
INTERNAL: Allocating one item from KMAP ENTRY(0xc0675640)
Allocating one item from PV ENTRY(0xc06758c0)
uma_zalloc_arg: Bucketzone returned NULL
INTERNAL: Allocating one item from PV ENTRY(0xc06758c0)
Allocating one item from PV ENTRY(0xc06758c0)
uma_zalloc_arg: Bucketzone returned NULL
INTERNAL: Allocating one item from PV ENTRY(0xc06758c0)
UMA startup2 complete.
INTERNAL: Allocating one item from UMA Zones(0xc0622fbc)
16(0xc0675b40) size = 16 ipers = 239 ppera = 1 pgoff = 3832
INTERNAL: Allocating one item from UMA Zones(0xc0622fbc)
32(0xc0675c80) size = 32 ipers = 123 ppera = 1 pgoff = 3948
INTERNAL: Allocating one item from UMA Zones(0xc0622fbc)
64(0xc0675dc0) size = 64 ipers = 62 ppera = 1 pgoff = 4008
INTERNAL: Allocating one item from UMA Zones(0xc0622fbc)
slab_zalloc: Allocating a new slab for UMA Zones
Allocating one item from KMAP ENTRY(0xc0675640)
INTERNAL: Allocating one item from UMA Buckets(0xc0675280)
uma_zalloc_arg: Bucketzone returned NULL
INTERNAL: Allocating one item from KMAP ENTRY(0xc0675640)
Allocating one item from PV ENTRY(0xc06758c0)
INTERNAL: Allocating one item from UMA Buckets(0xc0675280)
slab_zalloc: Allocating a new slab for UMA Buckets
panic: lockmgr: locking against myself
Debugger("panic")
Stopped at 0xc04f4330:mov r2, #0x
Here's a trace of the calls leading to the panic
Debugger
panic
lockmgr
_vm_map_lock
kmem_malloc
page_alloc
slab_zalloc
uma_zalloc_internal
uma_zalloc_arg
pmap_get_pv_entry
pmap_insert_entry
pmap_enter
kmem_malloc
page_alloc
slab_zalloc
uma_zalloc_internal
uma_zcreate
kmeminit
mi_startup
locorestart
If any other information is needed (code, memory dumps, etc...)
don't hesitate to ask.
Thanks in advance!
Steph
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: NetBSD's uvm_pglistalloc equivalent?
On Tue, Jul 16, 2002 at 01:54:04PM -0700, Terry Lambert wrote: > "Stephane E. Potvin" wrote: > > > How often must this be allocated? > > > > > > How many of them are needed? > > > > > > If you only need a small set number of them, then they can be > > > allocated very early on in the system lifetime, which means > > > you should allocate them in machdep.c, with the rest of the > > > memory overlay which attempts to make memory in protected mode > > > look like physical RAM. > > > > I need one per process to hold the L1PT of the process' vm space. I will > > probably implement a cache to avoid creating/destroying repetitively but I > > don't think that it's reasonable to preallocate them as it will wire too > > much physical memory. > > So your answers are: > > o Allocated on every fork, freed on every exit > > o One per process > > I don't know how you have the ARM memory map laid out. One thing > that FreeBSD does -- and why I suggested machdep.c -- is to map > out page mappings, without providing backing store for those > mappings until later. > > I guess I need a clarification on your original statement: > > > > > table of the StrongARM processor is four pages. These pages > > > > need to be allocated contiguously. > > The questions are: > > o Contiguous in physical memory? yes/no > > o Contiguous in kernel virtual memory? yes/no > > o Mapped at all in user virtual memory? yes/no > > o Contiguous in user virtual memory? yes/no > > If it's just in kernel virtual memory, then the approach I > suggested -- using machdep.c -- is the correct one. > Ok, here are your answers: 1. Contiguous in physical memory? yes 2. Contiguous in kernel virtual memory? not mandatory but would be nice 3. Mapped at all in user virtual memory? no 4. Contiguous in user virtual memory? no This memory area is for the l1 table and is similar to the x86 l1 table, the only difference is the size of the table. On x86 processors, you have 1024 l1 entries (for a total of 4096 bytes or one physical page) per l1 table and each l2 table is 1024 entries (for a total of 4096 bytes or one physical page). In the ARM case, there is 4096 l1 entries (for a total of 16384 bytes or four physical pages) per l1 table and each l2 table is 256 entries (for a total of 1024 bytes or four l2 tables per physical page). The l1 table is mainly accessed by the processor as part of the virtual->physical translation and must be contiguous in physical memory for that reason. Steph To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NetBSD's uvm_pglistalloc equivalent?
On Mon, Jul 15, 2002 at 02:26:27PM -0700, Terry Lambert wrote: > "Stephane E. Potvin" wrote: > > In my porting effort to the ARM platform, I need a function that has the > > functionality of NetBSD's uvm_pglistalloc. This is needed because the L1 > > table of the StrongARM processor is four pages. These pages need to be > > allocated contiguously. I guess that I can probably acheive this goal by > > wrapping something around contigmalloc, but before I do so I just wanted > > to double check that there was no already available facilities that I had > > overlooked. > > How often must this be allocated? > > How many of them are needed? > > If you only need a small set number of them, then they can be > allocated very early on in the system lifetime, which means > you should allocate them in machdep.c, with the rest of the > memory overlay which attempts to make memory in protected mode > look like physical RAM. I need one per process to hold the L1PT of the process' vm space. I will probably implement a cache to avoid creating/destroying repetitively but I don't think that it's reasonable to preallocate them as it will wire too much physical memory. Steph To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NetBSD's uvm_pglistalloc equivalent?
In my porting effort to the ARM platform, I need a function that has the functionality of NetBSD's uvm_pglistalloc. This is needed because the L1 table of the StrongARM processor is four pages. These pages need to be allocated contiguously. I guess that I can probably acheive this goal by wrapping something around contigmalloc, but before I do so I just wanted to double check that there was no already available facilities that I had overlooked. Thanks in advance! Steph To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD for ARM processor
On Tue, Jul 24, 2001 at 07:51:28AM -0700, David O'Brien wrote: > On Mon, Jul 23, 2001 at 09:39:18PM -0400, Stephane E. Potvin wrote: > > > > FreeBSD 5.0-CURRENT #271: Sun Jul 22 08:36:22 EDT 2001 > > > > >[EMAIL PROTECTED]:/usr/local/users/spotvin/work/FreeBSD/src/sys/arm/ > > > > compile/NETWINDER > ..snip.. > > > I'll try to post my work next weekend so people could have a peek at it. > > Please do so on the [EMAIL PROTECTED] mailing list. > This is also important as we'd like all new platforms to follow the > "FreeBSD" way. (granted it is being defined along with the other new > platform work going on) > > > I'm currently using a netwinder 275 for my development. It's a SA110 based > > machine with a 21285 (aka footbridge) host controller. You can check > > http://www.netwinder.org/ for more details about the machine. > > These machines are almost impossible to find, and very expensive when you > do find one. Are you open to developing on a DEC DNARD(shark) instead? > More people have these and I can put one in your hands. I have no problems whatsoever developing on a DEC DNARD or a CATS board. I'm currently working on a netwinder for no better reason that it's the only one I have available right now. I tried in the past to get hold of something else but so far all my attemps failed. Steph To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD for ARM processor
On Sun, Jul 22, 2001 at 03:10:56PM -0500, Alfred Perlstein wrote: > * Stephane E. Potvin <[EMAIL PROTECTED]> [010722 07:57] wrote: > > I tought that some might be interested by this: > > > > Copyright (c) 1992-2001 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > sysinit->subsystem 0x0081 > > FreeBSD 5.0-CURRENT #271: Sun Jul 22 08:36:22 EDT 2001 > > [EMAIL PROTECTED]:/usr/local/users/spotvin/work/FreeBSD/src/sys/arm/ > > compile/NETWINDER > > sysinit->subsystem 0x0100 > > <... some more subsystems ...> > > sysinit->subsystem 0x0840 > > panic: spin lock (null) held by 0 for > 5 seconds > > Uptime: 0s > > Automatic reboot in 15 seconds - press a key on the console to abort > > > > If there's any interest, I will continue to keep the list posted of my progresses. > > It'd be really cool if you could post your work somewhere along with > a description of the hardware you're using so we could check it out. > > Are there any simulators that you know of? I'll try to post my work next weekend so people could have a peek at it. I'm currently using a netwinder 275 for my development. It's a SA110 based machine with a 21285 (aka footbridge) host controller. You can check http://www.netwinder.org/ for more details about the machine. The only simulator that I'm aware of is the one that come with the ARM Developer Suite from ARM Ltd. Unfortunately, it costs a buch of money (at least for my budget :) and it only support binaries created with their toolchain. Steph To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
FreeBSD for ARM processor
I tought that some might be interested by this: Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. sysinit->subsystem 0x0081 FreeBSD 5.0-CURRENT #271: Sun Jul 22 08:36:22 EDT 2001 [EMAIL PROTECTED]:/usr/local/users/spotvin/work/FreeBSD/src/sys/arm/ compile/NETWINDER sysinit->subsystem 0x0100 <... some more subsystems ...> sysinit->subsystem 0x0840 panic: spin lock (null) held by 0 for > 5 seconds Uptime: 0s Automatic reboot in 15 seconds - press a key on the console to abort If there's any interest, I will continue to keep the list posted of my progresses. Steph To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ifconfig panic using 3C574 card
ibute memory device information: Device number 1, type EEPROM, WPS = OFF Speed = 150nS, Memory block size = 8Kb, 1 units Tuple #3, code = 0x20 (Manufacturer ID), length = 4 000: 01 01 74 05 PCMCIA ID = 0x101, OEM ID = 0x574 Tuple #4, code = 0x21 (Functional ID), length = 2 000: 06 00 Network/LAN adapter Tuple #5, code = 0x15 (Version 1 info), length = 46 000: 04 01 33 43 6f 6d 00 33 43 35 37 34 2d 54 58 20 010: 46 61 73 74 20 45 74 68 65 72 4c 69 6e 6b 20 50 020: 43 20 43 61 72 64 00 41 00 30 30 31 00 ff Version = 4.1, Manuf = [3Com],card vers = [3C574-TX Fast EtherLink PC Card] Addit. info = [A],[001] Tuple #6, code = 0x1a (Configuration map), length = 6 000: 02 03 00 00 01 03 Reg len = 3, config register addr = 0x1, last config = 0x3 Registers: XX-- Tuple #7, code = 0x1b (Configuration entry), length = 15 000: c1 01 1d 71 55 35 55 54 e0 72 5d 65 30 ff ff Config index = 0x1(default) Interface byte = 0x1 (I/O) Vcc pwr: Nominal operating supply voltage: 5 x 1V Max current average over 1 second: 3 x 10mA Max current average over 10 ms: 5 x 10mA Power down supply current: 5 x 1mA Wait scale Speed = 7.0 x 100 ns RDY/BSY scale Speed = 7.0 x 100 ns Card decodes 18 address lines, full 8/16 Bit I/O IRQ modes: Level, Pulse IRQs: IOCK 1 4 5 6 8 10 11 12 14 Tuple #8, code = 0x19 (JEDEC descr for attribute memory), length = 3 000: 00 00 ff Tuple #9, code = 0x14 (No link), length = 0 Tuple #10, code = 0x10 (Checksum), length = 5 000: 9d ff 6c 00 00 Checksum from offset -99, length 108, value is 0x0 Tuple #11, code = 0xff (Terminator), length = 122 000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 050: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 060: 00 00 00 00 74 00 00 00 02 00 07 00 62 01 1b 00 070: 00 00 86 10 ff ff 00 00 10 20 2 slots found config file: # # ALEXIS - kernel configuration fle # machine i386 cpu I586_CPU ident ALEXIS maxusers32 makeoptions DEBUG=-g options INCLUDE_CONFIG_FILE options CPU_FASTER_5X86_FPU options COMPAT_43 options USER_LDT options SYSVSHM options SYSVSEM options SYSVMSG options DDB options KTRACE options UCONSOLE options INET options ICMP_BANDLIM options FFS options FFS_ROOT options SOFTUPDATES options MSGBUF_SIZE=32768 options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L options PSM_HOOKAPM options PSM_RESETAFTERSUSPEND options PCIC_RESUME_RESET pseudo-device ether pseudo-device loop pseudo-device bpf pseudo-device pty pseudo-device speaker pseudo-device gzip controller isa0 controller pnp0 controller atkbdc0 at isa? port IO_KBD controller ata0 at isa? port IO_WD1 irq 14 controller fdc0 at isa? port IO_FD1 irq 6 drq 2 controller pci0 controller smbus0 controller intpm0 controller ppbus0 controller card0 controller pcic0 at isa? controller pcic1 at isa? device atkbd0 at atkbdc? irq 1 device vga0 at isa? port? conflicts device sc0 at isa? device npx0 at nexus? port IO_NPX irq 13 device atadisk0 device atapicd0 device fd0 at fdc0 drive 0 device sio0 at isa? port IO_COM1 irq 4 device smb0 at smbus? device lpt0 device ppc0 at isa? port? irq 7 device psm0 at atkbdc? irq 12 device ep0 device apm0 -- Stephane E. Potvin InnoMediaLogic Inc. - http://www.multichassis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARM support
Mike Smith wrote:
>
> > To whoever that may interest, I've now got a nearly working freebsd
> > loader for the NetWinder. It currently only uses the serial console and
> > miss internal hard driver support but work is underway for both these
> > issues.
>
> Cool! Does the NetWinder use OpenFirmware, or some other firmware
> interface?
Unfortunately no. It uses a stripped down linux kernel as firmware.
That's why I switched to work on the bootloader: the darn thing doesn't
seems to grok ufs right. It's bad because the disk/video support have to
be done from the ground up. Adding support to the Shark/acorn computers
will probably be a lot easier.
> > I'm making some progress too in getting world to compile but work in
> > this area is more slower as I've got no way to test what I compile and
> > I'm not that at ease with most of the code.
>
> If you're interested in sharing your work, I have a DNA ('shark') here
> that was loaned to the Project for just this purpose. I'd be really
> interested to see your cross-build bits integrated into our tree ASAP.
I'd really like this to happens too but right now I think that would be
near impossible. binutils 2.9.1 doesn't really support arm/elf so I'm
currently using a recent snapshot of binutils (2.9.5) with gcc 2.95.1.
I'm using a boatload of very ugly hacks to make this combitation work
with current...
As soon as the binutils crew releases something more official so that it
could be added into the tree I'll be more than happy to send pr's for
what I've got so far.
Steph
--
Stephane E. Potvin
InnoMediaLogic Inc. - http://www.multichassis.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
ARM support
To whoever that may interest, I've now got a nearly working freebsd loader for the NetWinder. It currently only uses the serial console and miss internal hard driver support but work is underway for both these issues. I'm making some progress too in getting world to compile but work in this area is more slower as I've got no way to test what I compile and I'm not that at ease with most of the code. -- Stephane E. Potvin InnoMediaLogic Inc. - http://www.multichassis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
gas pseudo-ops
Does anyone have any idea where I could find some documentation about the following gas pseudo-ops? .type ,@object .previous Both are used in setdef0.c used to generate linker sets but does not seems to be documented in the gas info file, the man page or the faq. Thanks in advance! -- Stephane E. Potvin InnoMediaLogic - http://www.multichassis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gas pseudo-ops
John Polstra wrote: > > In article <01bf260d$837c8770$[EMAIL PROTECTED]>, > Stephane Potvin <[EMAIL PROTECTED]> wrote: > > > > Do you think it would be possible to change the > > .type ,@object > > for > > .type ,object > > in gensetdef? By looking in the gas code I found that the assembler just > > ignores the @ character. > > I think it would be much better to remove all of the platform-specific > asm statements from gensetdefs and put them into a header > . Gensetdefs would then emit an include of that > header to get the needed definitions. > > This isn't very high on my personal priority list, though. Fair enough. Anyway, I'm currently using a local gensetdefs for the arm part as is done with the alpha instead of the default gensetdefs. So far it's working pretty well so I'll let it that way for the time being. Thanks for the answer though. Steph -- Stephane E. Potvin InnoMediaLogic Inc. - http://www.multichassis.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
