|
|
| Author |
Message |
| 25 new of 292 responses total. |
pfv
|
|
response 150 of 292:
| 
Oct 29 21:06 UTC 1999 |
Oy, geezus.. I had something like that "buss error" thing for
awhile.. Damned catchall is as bad as a GPF.. Fixed it, but gad..
It was depressing.
|
mdw
|
|
response 151 of 292:
|
Oct 29 22:27 UTC 1999 |
What SIGBUS means is hardware dependent, but originally (on the pdp-11 &
vax), it meant an attempt to fetch a word on a non-word boundary -- an
"alignment" error. Many modern machines can fetch words on non-aligned
boundaries (usually with a small performance penalty) so this is not as
likely. The i86 can do unaligned fetches. The 68000 and 68010 require
everything except bytes be at even addresses. The 68020 and + can do
aligned data fetches, but still require that the stack & program counter
be even. The sparc and power risc architectures can't do aligned
fetches. Most powerpc implementations can do aligned data fetches (but
would require word aligned stack & instructions.)
In openbsd, apparently, you'd have to do a systemcall that somehow
invalidates the current stack or data segment; perhaps a call to mmap.
|
pfv
|
|
response 152 of 292:
|
Oct 29 23:13 UTC 1999 |
That was precisely the problem, too.. I had some code developed
(apparently) for DOS that relied on data being so & so arrayed..
I was pretty sure it was that, but I was too tired that day to
track it further.. Thankfully, another grexer took the reins and
slammed out a solution..
Sorta' a Terrible-Day & then the Sun-Came-Out, thang..
|
gelinas
|
|
response 153 of 292:
|
Oct 30 00:17 UTC 1999 |
(Marcus, did you sometimes use "aligned" above when you meant "unaligned"?)
|
mdw
|
|
response 154 of 292:
|
Oct 30 03:25 UTC 1999 |
(Probably. Are you studying to be a proof-reader?)
|
gelinas
|
|
response 155 of 292:
|
Oct 30 03:27 UTC 1999 |
(No, it's a curse.)
|
hhsrat
|
|
response 156 of 292:
|
Oct 30 03:28 UTC 1999 |
(Who's this General Protection dude, and why is everything always his
fault? :)
|
tpryan
|
|
response 157 of 292:
|
Oct 30 15:45 UTC 1999 |
He took over from General Mills.
|
krj
|
|
response 158 of 292:
|
Nov 3 05:28 UTC 1999 |
/a is almost full, someone in party was complaining about a lost
participationf ile.
|
gelinas
|
|
response 159 of 292:
|
Nov 3 06:09 UTC 1999 |
Well, it's at 100% right now, and my part file was merely corrupted. I've
not deleted it yet.
|
aruba
|
|
response 160 of 292:
|
Nov 3 13:44 UTC 1999 |
I lost my participation file to /a last night.
|
drew
|
|
response 161 of 292:
|
Nov 4 20:27 UTC 1999 |
Time to put in one of those extra hard drives, and move half of /a to it.
|
richard
|
|
response 162 of 292:
|
Nov 5 20:42 UTC 1999 |
Arrgh, are vandals attacking the /a drive again and filling it up?
Im getting a "bad participation file" message every time I log on, and
my conf bookmarks arent being kept upto date. How can I fix?
|
other
|
|
response 163 of 292:
|
Nov 5 20:56 UTC 1999 |
yeah, richard! quit taking up so much drive space! ;)
|
gull
|
|
response 164 of 292:
|
Nov 5 21:17 UTC 1999 |
Keep a big junk file around, so when the drive fills up, you can delete it
and get enough space to save your participation file. ;>
(I'm kidding. Don't do that, it's not polite.)
|
goose
|
|
response 165 of 292:
|
Nov 6 21:34 UTC 1999 |
HELLO STAFF?!? /a ihas now become a chronic problem.......
|
krj
|
|
response 166 of 292:
|
Nov 7 06:46 UTC 1999 |
Yes, the /a problem just trashed another participation file of mine.
|
sno
|
|
response 167 of 292:
|
Nov 7 15:29 UTC 1999 |
Why can't a link be used for certain groups' home directory to a known
viable space on another volume. It seems that waiting to repartition
doesn't fix the problem very fast.
|
jazz
|
|
response 168 of 292:
|
Nov 7 16:53 UTC 1999 |
I'd thought about that, or taking an additional step, and creating a
partition specifically for BBS partition files. The only advantage here is
that the volume would be easier to manage when conferences are dismanted (if
they are here, I haven't seen it happen, but it was a mess on m-net) - it's
still a limited volume and will still fill up. :)
|
scg
|
|
response 169 of 292:
|
Nov 7 17:20 UTC 1999 |
I switched newuser over yesterday so that it is now creating new accounts on
the /c partition instead. I fell asleep in the middle of trying to clear up
space on /a.
|
jazz
|
|
response 170 of 292:
|
Nov 7 17:43 UTC 1999 |
It's a tough job, Steve. Good luck. Have you considered changing the
reaping times for inactive accounts?
|
hematite
|
|
response 171 of 292:
|
Nov 8 04:08 UTC 1999 |
How does one get switch the new menu system back to the old one?
|
mcnally
|
|
response 172 of 292:
|
Nov 8 04:50 UTC 1999 |
Given that:
1) the people who intentionally vandalize the system by filling up
filesystems in a denial-of-service attack generally do so from
new accounts, not long-established ones, and that
2) "filesystem full" problems are of particular annoyance to conference
participants..
Would it be profitable to consider a home-directory allocation scheme
where long-established accounts with a history of mostly stable disk-
usage were grouped together on one or more partitions set aside for
the purpose? If the majority of long-time confer participants had home
directories which were physically segregated away from newuser accounts
it seems like many of the surprise filesystem problems which affect
Picospan users could be diverted..
|
orinoco
|
|
response 173 of 292:
|
Nov 8 05:13 UTC 1999 |
That sounds like it would just be inviting trouble, though. Who would
determine who gets to be a "special user" with a stable directory? Wouldn't
giving accounts which are likely to lose their participation files to new
users tend to make conferencing difficult for the people we're trying the
hardest to attract to the conferences?
It seems to me that the scheme John mentions in #168 would have a similar
effect -- putting all the participation files someplace away from all the
home directories would make vandalism less likely to trash them, right? --
but without discriminating between long-time conferencers and everyone
else. Then again, I may be wrong.
|
jazz
|
|
response 174 of 292:
|
Nov 8 12:44 UTC 1999 |
Well, never attribute to malicious hackers what can easily be explained
by thousands of bored "software engineers" and other twits.
|
