Need clues on possible brokenness.

2001-04-10 Thread Chad Schwartz
Hiya, list. Think i've found a rather nasty bug in the kernel, and I need some clues as to where to look for the issue. Stats: Quad Xeon (PIII core) 700mhz machine (1mb cache on each) 4gb RAM 5x36gb SCSI disks - on a DAC1100 RAID controller 3 EEPro 100 cards The box functions as a database ser

Re: why getch() cann't work in rpm package's %post section?

2001-01-05 Thread Chad Schwartz
This is *NOT* a kernel question. Take this kind of stuff elsewhere. The reason? RPM is NOT meant to take any input, on installation of a package. if you're trying to do that, you're doing it the wrong way. Chad On Wed, 6 Dec 2000, kouqian wrote: > a program using getch() function (included in

Re: Linux 2.2.19pre3

2000-12-22 Thread Chad Schwartz
> And which of the versions of 'which' would you rather people had. Do you want > csh behaviour, tcsh behaviour, which non builtin BSD behaviour, which as alias > trick behaviour, which as ksh behaviour.. > > There is no standard which command. Exactly why there will be 3 different overall behavi

Re: Linux 2.2.19pre3

2000-12-22 Thread Chad Schwartz
> alias kwhich='type -path' in ~./bashrc should fix. I don't know > why 'standard' Unix/sell/executable commands keep getting changed > to GNUisms in distributions. I've been asking that question ever since most popular distributions started putting a copy of bash in /bin/sh. WHY oh WHY would th

Re: Dropping chars on 16550

2000-12-16 Thread Chad Schwartz
absolutely, they are. They don't follow the same archaic I/O register mechanism, either. which is *GOOD*. (Just take a peak at the 16C854 sometime. You'll understand exactly how archaic it can GET.) Chad > > macs and sun machines use z85c30 chips, so there are some non-16550 boxes > > out ther

Re: Dropping chars on 16550

2000-12-16 Thread Chad Schwartz
heh. yep. Thats why I didn't list them. z85's are good chips, but they perform JUST LIKE a 16550. Chad > On Thu, Dec 14, 2000 at 08:51:42AM -0600, Chad Schwartz wrote: > > And what kind of serial ports do you find on your Alpha? 16550's! Your > > PowerPC? 165

Re: Dropping chars on 16550

2000-12-14 Thread Chad Schwartz
> > This is where a 654 or an 854 (I'm only listing startech design chips. > > there are others that would do the job.) come in handy. They can pause > > their transmitter WITH bytes in their fifo. (Automated hardware/software > > flow control.) > > Indeed. Most chips I've seen are 1 16550, or pr

Re: Dropping chars on 16550

2000-12-13 Thread Chad Schwartz
> > Heh...do what I did. Go on eBay and pick up a Hayes ESP card. > > Hmm.. High speed comm is fine here, as long is I use handshaking. If I > don't, I'll loose chars. there are many situations in which a 16550 is KNOWN to be overrunable, all of which can occur in your common PPP connection. Mo

Re: Dropping chars on 16550

2000-12-10 Thread Chad Schwartz
You'll find that there is a problem with 2.2.12, on down - with losing a few bytes here and there. The bug is in the tty subsystem - in that when you pass off chars to the ldisc - from the driver, the ldisc doesn't actually write them. (I could get into the details, but you probably don't care.)

Re: Serial Console

2000-12-05 Thread Chad Schwartz
See, in an ideal world, that shouldn't be the case, at all. Since we're NOT operating under the assumption that the serial console is a modem, we should be - instead - operating under the assumption that it is a 3-wire NULL connection. (thus, making NO assumptions about the user's hardware..) If

Re: Serial Console

2000-12-05 Thread Chad Schwartz
Unless of course you really DO have RTS/CTS (Or DTR-->CTS) flow control turned on - on your terminal, and the terminal shuts off RTS (or DTR) to indicate its fifo level is too high. That *IS* useful. but the ability to hard-code it in a shut-off state is *MUCH* better. Chad > On Tue, 5 Dec 200

Re: Serial Console

2000-12-05 Thread Chad Schwartz
> Nope, /dev/console *does* block. ATM I've found a quick workaround - I > use "stty -F /dev/console clocal -crtscts" to turn off the serial flow > control at the stawrt of /etc/rc.d/rc.sysinit - this seems to work quite > well... of course it doesn't stop some program turning flow control back >

Re: Kernel bits

2000-11-27 Thread Chad Schwartz
> No, that only tells you the size of a long under the compiler you used. > If you are on an Intel IA64 (64 bit kernel) but you compile with gcc > for ix86 (32 bit userspace) then sizeof(long) is 4. IA64 runs both > native and ix86 code, sizeof(any userspace field) tells you nothing > about the k

Re: Kernel bits

2000-11-27 Thread Chad Schwartz
int main(void) { printf("Size of an unsigned long is %d bytes\n",sizeof(unsigned long)); return(0); } That simple program will tell you that an unsigned long is 4 bytes, or 8 bytes. It is then a safe assumption - that if you get back '8', that you're running a 64bit kernel, on a